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ABSTRACT 





The Troop Command at the Presidio of Monterey requires an information system 
that will provide timely and accurate data about all serviced troop activities with students 
and permanent party stationed at the Defense Language Institute Foreign Language 
Center. Data sources that could provide required information already exist, but are 
physically spread over the Presidio, are maintained in diverse formats, and are not 
interconnected. Some data sources, maintained by other activities located at the 
Presidio, are available on the Campus Area Network. As new technologies emerged, it 
became possible to integrate all available data sources into a heterogeneous distributed 
information system, in which some information will be shared, while other information will 
be under some degree of local control. This thesis studies the feasibility of such an 


information system, and proposes one possible implementation. 
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l. INTRODUCTION 


A. BACKGROUND 

Numerous local databases are maintained simultaneously by military units at the 
Presidio of Monterey (POM). Each database implements its own proprietary database 
schema, and data are stored in a variety of formats (Paradox, Excel, MS Access, 
proprietary file system, Word document, etc.). Often, one local database consists of 
several unconnected mini databases. Because of such diversity, integration of these 
databases into one interconnected system ts virtually impossible. As a result, data 
cannot be shared between units, nor can be queried by global users at the troop 
command level. In order to allow querying the data by global users, and to allow sharing 
of data between the units, these databases need to be integrated into one database 
system. 

A standard database, named Military Student Database (MILDB), that contains 
all logical data items needed to be maintained by each unit, has been designed and 
locally implemented at some units. MILDB users continuously update and query their 
local databases. However, many data items, normally entered into MILDB at the unit 
level, already exist in a networked database maintained elsewhere at the Presidio of 
Monterey. In order to allow effective data sharing between these local databases and 
networked databases, they need to be integrated into one heterogeneous, distributed 
database system. Selection of appropriate database management systems that will 
support heterogeneous queries will be proposed. Since only some MILDB users have 
permanent access to Campus Area Network (CAN), while other users will connect to 


CAN only occasionally via modem, MILDB databases need tosynchronized. Mechanism 


for reliable, bi-directional synchronization of heterogeneous databases will be, therefore, 


proposed. 


B. SCOPE 

The scope of this thesis is to design and implement an information system, 
consisting of a multitude of local MILDB databases occasionally connected to a central 
MILDB database. This database system will be supported by a single interface which will 
be installed on every user’s workstation, and will have the capability to communicate 
with both the central and local MILDB databases. 

It will be taken into account that different system and performance requirements 
will apply for the central and local databases. The first step is the selection of 
appropriate database management system for each database. Chapter Ill, part B 
addresses this issue. The central database will contain data from all Units and will also 
contain other information, not related to MILDB. The second step, described in section E 
and F of Chapter III of this thesis, is to design and implement a strict system of access 
control which will provide information to users on need-to-see basis. The third step is to 
develop a user friendly and intuitive interface that will provide means for easy data 
updates, quick retrieval of data into canned or custom reports, and for bi-directional data 


synchronization. Section V of this thesis documents the development of the MILDB 


application interface. 











C. ORGANIZATION OF THESIS 


Chapter |: Introduction. Describes the project and identifies major areas of 


concern. Indicates steps that will be taken to resolve the project. 


Chapter Il: Information System Analysis. Provides analysis of hardware and 


software requirements on a workstation of a typical MILDB user. Detailed requirements 


for MILDB graphical! user interface are also specified. 


Chapter Ill: Knowledge Systems. Provides a general overview of database 
management systems (DBMSs), and major components of relational DBMS model. 
Selection of DBMS for local MILDB and the central database is proposed and justified. 


Data security is studied, and mechanism for controlling data access is proposed. 


Chapter IV: Client Server Architecture. Applicability of two-tier and multi-tier 


architecture to MILDB is studied. Selection of client server model is made and justified. 


Chapter V: Developing Database Application in PowerBuilder 7. Provides an 


overview of major features in PowerBuilder 7 for Windows. Describes how was 
PowerBuilder applied to develop the MILDB application interface, and to perform 
database transactions. Database connectivity through major database interfaces is also 


studied. 


Chapter VI: Conclusion. Summarizes lessons learned, and proposes areas for 


further research. 
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ll. INFORMATION SYSTEM ANALYSIS 


A. HARDWARE 
Initially, local record keeping at Unit level was performed on PCs fitted with Intel 
386 or 486 processor, 4MB to 8MB RAM, and 80 to 120 MB harddrive. 14in monitor 
was a standard. This was sufficient to run DOS, or simple Windows-based applications 
running in Windows 3.1 environment. At the time of implementation of the thesis, all 
potential users of MILDB were equipped with workstations having the following 
parameters: 
Processor: Pentium 266 MHz 
RAM: 64 MB 
Hard Drive: 8 GB 
(Modem): 33.3 K 
(Network card): Ethernet 3COM 10-100 


Monitor: 17” 


Workstations are connected to Campus Area Network (CAN) via network card, or 
via modem. The central database was at the time of implementation of this thesis 
running on HP server fitted with four processors. 

In order to take advantage of new hardware capabilities of the typical 
workstation, the original version of MILDB was redesigned and upgraded to 
PowerBuilder 7. This, in turn, set new minimum hardware requirements for workstations 


intended to run MILDB: 





Processor: Pentium 90 MHz + 
RAM: 32 MB 
Hard Drive: /” MB 
Monitor: 17° 


Operating System: WIN 95+ or WINT NT 4+ 


B. SOFTWARE 


The typical MILDB user uses PC with the following software preinstalled: 


Operating System: Windows NT 4.0 Workstation 
Service Pack 4 or higher 


Other Essential Software: Office 97 with 


Microsoft Access 97 


Hard Drive 32 bit ODBC Administrator 


It is apparent that the typical user of MILDB at POM works on a workstation that 


exceeds the minimum hardware and software requirements for running a PowerBuilder / 


application. 





G: INTERFACE 
1. Goal 


Develop a Windows based, event driven GUI as the sole means of 
communication with a database to be used by military personnel with computer skills 
ranging from novice to expert, who should become at vere 80% proficient in using all 
GUI's features (i.e., be able to readily locate specific function feature and use it 


effectively) after less than 30 min of introductory briefing. 


2. Features 


e Maintains records of service members in three distinct areas: Administration, 
Physical Training, and Dormitory Assignment. Maintaining records includes: 
create new or locate existing record of service member. enter/update data, 


deactivate or permanently delete a record. 
e Generates and displays canned (pre-designed) or ad hoc query reports. 


e Prints a report, or exports report as a text file. 


¢ Allows display/modification of data of personne! grouped by individual units 
(viewed only by personnel from the unit), and also make all data from all units 
available to global users at troop command level. At troop command level, also 


generate summary reports across all units. 


e Minimizes the need of typing by providing optional selection from list of entries 


whenever practical/functional. 











3. User Analysis 
Users of the interface will be military personnel with computer skills 
ranging from novice to advanced level., ranking from enlisted personnel to senior 
officers. Users with lower ranks, who will use MILDB daily, may fluctuate relatively often 
(every few months). Officers with higher ranks may be using the system only 
sporadically. Therefore, the interface has to be simple and intuitive enough, so that the 
primary users (enlisted personnel) can use the system effectively after less than 30 min 
of training, and occasional users (officers) will be able to reach the desired information 
easily without any outside help. 
Enlisted personnel (local users) will perform data entry and waintenance and will 


generate reports at the unit level. Senior personnel (global users) will mostly generate 


summary reporis. 


No specific typing skills are required. It is assumed that all users will, as a 


minimum, have high school diploma. 


4. Task Analysis 


a. Display interface, retrieve data in following record 
categories: 
(1) Admin/Biographical 
; Inprocessing ( biographical data, previous training, etc.). 
e Individual Information ( pregnancy counseling, family care, chapter 


discharge). 


e Individual History ( training, flags, qualifications, disciplinary actions). 








Outprocessing ( deactivate record, permanently delete record). 


Reports/Schedules ( rosters, reports, training plans). 


(2) Physical Training 
Weight Control ( male & female separately), data entry and evaluation. 
Army Physical Fitness Test (APFT), data entry and evaluation. 
Profiles, data entry. 
Profiles, custom query. 
Individual’s weight history (report). 
Individual’s APFT history (report). 
APFT, custom query. 
Weight Control, custom query. 


Physical Training, custom query. 


(3) Dormitory Assignment 
Check person in. 
Check person out. 
Show assigned and available rooms. 


Show unassigned personnel. 


b. Enter new service member into database (a(1) only) 
Display fields for data entry. 


Verify validity of data ( SSN, dates, class name). 


List entry options (when feasible). 








Automate data entries ( DOB -> age, ZIP -> city name). 


c. Locate a service member in database (a(1) and a(2)) 
Retrieve & display list of all personnel in unit (Company). 
Retrieve & display list of all personnel in sub-unit (platoon). 


Retrieve & display individual's records of specific category. 


d. Enter/Modify data 
Indicate field to be filled/modified. 
Verify data validity (SSN, date format, class name). 


Allow entries for group of records whenever feasible. 


e. Save changes to records 
Verify validity of data. 


Save changes to individual or multiple records. 


f, Generate reports 
Retrieve & display data in pre-designed reporis. 
Retrieve & display data in ad hoc query reports. 
Display list of data items available for query. 


Generate custom report. 


g. Print reports 


h. Export report data to a text file 
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Functional analysis 


a. Display interface for record category _ 
Open window ( new window for each group). 
Setup window for Admin/Bio. 
Setup window for Physical Training. 


Setup window for Dormitory Assignment. 


b. Enter new service member into database (a(1) only) 


Setup Admin/Bio for new record. 


c; Locate a service member in database (a(1) and a(2)) 


Show personnel in unit/sub-unit. 


Retrieve data for selected/highlighted individual in currently active window. 


d. Enter/Modify data - Verify validity of data. 


Navigate to the next field. 


e. Save changes fo records. 


Update database. 


f. Generate reports 


Setup data-viewer window for specific report. 
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For ad hoc query: 


Open Query Builder window. 
Retrieve/display list of table columns. 
Build query from selected data items. 


Retrieve/display data. 


_g. Print reports 


Call PRINT() utility in active window. 


h. Export report data to a text file 


Call EXPORT() utility in active window. 


D. DATA COMMUNICATION 


The current trend at POM is to connect every workstation to CAN. However, until 


this happens, some workstations need to connect to CAN via modem through telephone 


network, using terminal Server Access Controller System (TSACS). Such connections 


are not intended for continuous 24hr/day operation. Also, the typical database 


transaction executed via TSACS takes seconds or minutes, rather than milliseconds or 


seconds. Many MILDB transactions require retrieval of several reference data, before 


other queries can be formulated and executed. This would lead to significant time delays 


in execution of MILDB transactions, which would also make the use of the central 


database impractical. Rather, users without permanent connection to CAN should work 


on a local MILDB database, and regularly synchronize data with the central database. 
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lll. KNOWLEDGE SYSTEMS 


A. INTRODUCTION 

Database is a collection of data serving some specific purpose. When applied in 
information system, this collection is usually also formally structured. In order to be 
considered a database, data don’t have to reside in one location only. Rather, as it 
becomes typical today, data can be geographically distributed among several data 
repositories. 

In order to be able to retrieve a specific data item from database, one can 
engage in devising a software that will find the physical location of data in data 
repository, read appropriate number of bytes,. and format the output we a form, 
intelligible to the end user. A commercial database file system is an example of such 
approach. Then, according to some estimates, up .to 80% of a typical business 
application is dedicated to coding a file access mechanism and to editing and validating 
the input data, while only about 20% of the application logic is dedicated to formatting 
and processing data before being displayed as output. 

However, the mechanics of data storage and retrieval can be separated from 
database application and delegated to a separate software system, the Database 
Management System (DBMS). The database client application can then focus on 
business logic, data manipulation and presentation, while DBMS will store, modify, or 


extract data from database. 


13 


B. DBMS 

1. Overview 

Typical contemporary DBMS provides means for defining the type and layout of 
each data item (entity) to be stored in the database. These properties (attributes) can be 
referred to by a name (i.e., column name in a table). Data items (entities) are organized 
into larger wholes (tables, or relations). Various relationships and dependencies can be 
defined between tables (relations). Definitions of entities, definitions of relations, and 
relationships are parts of database schema, whichis stored and maintained in a system 
catalog. There are several tasks to be accomplished during implementation of a 
database: | 

e Planning (define entities, relations, interdependencies, etc.). 

e Construct a database (implement the plan). 

e Populate the database with data (store initial data). 

e Query the database (request, store new, or update existing data). 


e Maintain the database (compact the database, add/remove indexes, etc). 


To fulfil these tasks, we communicate with the DBMS using a language that 
DBMS understands. To create database objects (tables, indexes, and so on) we use 
Data Definition Language (DDL). In order to determine which values are present in a 
database at any given time, we use Data Manipulation Language (DML). Another 
_ language, Data Control language (DCL), is a set of commands that determine whether a 
eer has appropriate permissions to perform a particular action. In reality, these 


languages are not separate. Rather, they are divisions of commands of a single 
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language, Structure Query Language (SQL). SQL standard is defined by ANSI (the 
American National Standard Institute). All commercial DBMSs have to conform to SQL- 
89 standard. It is desirable, however, that new DBMSs conform to a newer, SQL-92 
standard. Various business applications and tool kits designed to interact with databases 
also provide a set of powerful commands that fulfil most of the tasks that SQL does. But 
they use simpler, more English-like languages, called fourth-generation languages 
(4GLs). Examples of such tool kits include PowerBuilder from Sybase, Visual Basic from 
Microsoft, Windows/4GL from Computer Associates, SQL-Forms from Oracle, and 


others. In this project, PowerBuilder 7 for Windows will be used. 


2. Preferred DBMS Requirements 
a. Interoperability 
(1) Hardware 
The DBMS should run on a variety of hardware platforms, fitted 
with one or more processors of no particular type. It should run on a single, off-line 
workstation, as well as in a multi-tier environment. [It should also be capable of 


interoperating with legacy systems at both the data and application level. 


(2) Database 
Without requiring a separate installation procedure, the DBMS 

should provide the following functioning: 
° Heterogeneous data access (select data from more then one database in a 
single query, either using native build-in mechanisms, or Open Database 


Connectivity interface). 
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e Transaction Integration (complete a query submitted using different kinds of 


query languages [SQL, Og], or interface languages [HTML, Java)). 


e Replication (ability of data modifications to non-native data stores, without the 


necessity of installing additional software). 


e Messaging System (ability to remotely notify administrators about system 


errors, or other messages via, for example, e-mail). 


b. DBMS Engine 


e Automatic, Transparent Database Tuning 

Based on usage patterns, reorganize data and index pages to improve 
performance, allocate additional memory space as needed, reclaim unused disk 
space in database files, verify integrity of data possibly compromised by 
hardware or software errors, cache the most frequently called stored procedures, 


verify data integrity by checking the structural integrity of data objects. 


e tndex Auto-Create 


Based on usage patterns, optimize accessing data by creating/dropping indexes 


that are not part of the original design. 


16 











e Database Statistics 


Automatically gather statistics about distribution of the data in the database for 


use by query optimizer, or database administrator. 


e Dynamic Configuration 
Continuously coordinate with the operating system a re-allocation of main 


memory, data and procedure cache. 


e Locking 
Based on the data amount, automatically determine the best locking strategy of 


records. 


e Query Processor 
Automatically optimize index maintenance, constraint checking, and parallel data 


load operations during import/export of large volume of data. 


e Cursors 
Enable locating/update of a record within a result set by supporting relative 


positioning indicated by graphical user interface. 


e Table Design 


Allow adding/removing columns regardless of data type, at any time and in any 


order, without loosing any data stored in database. 
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Cc. Administration 
e Interface 


Provide intuitive graphical interface for performing even elaborate administrative 


tasks. 


e Scriptable Administration 
Execute commands written in a variety of scripting languages, such as Java, 


Pearl, VB Script, etc. 


e Multi-server Administration 
Provide the ability to administer a multitude of subscribed servers from any 


workstation that has the administrative interface. 


d. Data Movement 


Integrate tools for data export/import from any type of data store. 


Transform/translate the data as it is moved from source to destination. 


e. Data Warehousing 


DBMS should include facility for creating, accessing, and manipulating a 


multidimensional database 


f. Replication 


DBMS should allow to replicate data to non-native data stores without the 


necessity to install additional software. 
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g. Tools 
e Data Tools 
Provide graphical tools for creation of database tables, queries, views, stored 


procedures, database diagrams, etc. 


e Maintenance Tolls 
Provide intuitive graphical interface for various administrative tasks, such as 


database creation, maintenance, performance tuning, replication setup, etc. 


3. DBMS Classification 
Range of data managed by DBMS may vary from simple to complex. Application 
that manipulates data may do so by means of queries, or without queries. In order to 
categorize few basic DBMSs, we will assume that data are either simple or complex, and 
application requires queries or does not require queries. Then we can describe four 
basic DBMS applications that manage: 
a. Simple Data with Queries 
A text editor is an example of a “no query” application. Text editor merely. 
opens a file, and either overwrites the existing content with a new one, or appends the 
file content. 
b. Simple Data without Queries 
Simple data are those that can be expressed using standard data types 


found in SQL-89 or SQL-92. They can be captured in a two-dimensional table such as: 
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CREATE TABLE Sailors( 


Name varchar(30), 
SSN varchar(9), 
Rank varchar(5), 
Unit varchar(2), 
DOB date, 
Weight integer); 


CREATE TABLE Units( 
Unit varchar(2), 
CmdrssNn varchar(Q), 


Location varchar(10)): 


To find all sailors serving at certain location (for example, POM), we can 


send the following query to the database: 
SELECT name 
FROM Sailors 
WHERE Unit in (SELECT Unit 
FROM Units 
WHERE location = ‘POM’): 


This type, or more complex, queries can be found in typical “business 


data processing” applications. 
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c. Complex Data without Queries 


Typical application that falls into this category is CAD, where the 
computer must handle many interconnected items, some of which are complex 
themselves. Changes to any item could require extensive modifications to other items, in 


order for integrity of drawings to be maintained. 


d. Complex Data with Queries 

A digital library of pictures is a good example of unifying both complex 
items and queries. Each picture is scanned, and the location of each picture and location 
of selected features within the picture are recorded. User may query the database to find 


all pictures from specific area, or all pictures that contain certain feature. 


For each of these case studies, a different DBMS is suited: 
e Simple Data without Queries File System 

e Simple Data with Queries Relational DBMS 

e Complex data without Queries. Object-oriented DBMS 


e Complex Data with Queries Object-relational DBMS 


All data in MILDB can be captured in 2-dimensional relations that will be 


queried. Relational DBMS (or, RDBMS) will be, therefore, studied and implemented. 
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4. Selection of RDBMS 

Units will maintain their data either in a local database running on a workstation, 
or in the central database running on a network server. Each local database will hold 
data on several hundreds of personnel. The central database will hold data on personnel 
measured in thousands. Local MILDB database will hold approximately 5 MB of data, 


and can be managed by a small DBMS, such as Microsoft Access. However, more 


involved queries, such as: 
DELETE FROM training 
WHERE ssn NOT IN (SELECT ssn 
FROM admin); 
can take minutes to complete even on a local database, which would be unacceptable 
for the central database, which will be queried simultaneously by many users. More 
powerful and effective database engine is needed for the central MILDB database. 
Microsoft SQL Server 7 was chosen to manage the central database. Brief description 


of selected DBMS$Ss follows. 


a. Microsoft Access 97 

Microsoft Access can contain all its objects in a single file (mdb). For this 
reason it is sometimes called a database container. Advantage of this fact is that the 
database file can be, when needed, easily transferred from one workstation to another 
and continue to function at the new location without any further special arrangements or 
| interruption. The MDB file can also be easily backed up by making a simple copy to a 
different location, or can be forwarded to a different location for repair, in case the user is 


not experienced enough to perform such operation on site. Access 97 contains build-in 
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features for easy data import/export from external non-native data stores, as well as for 
linking external data sources to the database without actually importing the data. MS 
Access also provides access contro! features. Access contro! will not be implemented on 
: local MILDB database, since access to this database will already be controlled by the 
authentication procedure of the operating system. 
System requirements for optimum performance: 
Processor. Pentium 
RAM: 16~20MB (under Windows 95+) 
32 MB (under Windows NT 3.51+) 
HARD Disk: 70 MB (for full installation of Access) 
10 MB (for database file) 
Operating System: Windows 95+ 


Windows NT 3.51+ 


Hardware and software specifications of typical user’s workstation meet, 


and exceed, the system requirements for MS Access 97. 


b. Microsoft SQL Server 7 

This product has evolved from DBMS developed by another relational 
DBMS vendor, Sybase. By today’s standards, the SQL Server 7 meets many of the 
preferred requirements listed earlier in this secton. Its strengths include ease of use 
and, more significantly, its support of very large databases. SQL Server has build-in 
features such as dynamic self-management, high performance on-line backup, support 


of heterogeneous queries and English queries, data warehousing, data transformation 
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services, and others. SQL Server 7 is able to take advantage of multi-processor servers, 
and claims to be able to access directly up to 32 GB of memory by using 64-bit 
addressing. This by far exceeds the needs of the central MILDB database, which will in 
the future hold records (current and historic) measured in tens of thousands. However, 
SQL Server will be also utilized to manage other databases as well. 
System requirements for optimum performance: 
Processor: Pentium 166 MHz + 
RAM: 32 MB minimum 
(64 MB recommended) 
HARD Disk: 70 MB (minimal installation) 
160 B (typical installation) 
Operating System: Windows 95+ 
Windows NT 4.0+ 
Service pack 4 or later 


Other: Internet Explorer 4.01+ 


Network server that meets and exceeds these requirements was procured. 


C. DATABASE MODEL 


5 Overview 
From technical point of view, DBMSs can widely differ. Major types of DBMSs 
are: relational, network, flat, hierarchical, and object-oriented. Each type vary by the way 


the DBMS internally organizes information, which in turn can determine how quickly and 
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flexibly a user can extract information from database. In previous section’ we have 
concluded that relational DBMSs will be applied in this project. It is, therefore, the 


relational data model that will now be further investigated. 


2. Relational Database Model 


Relational database model has three main parts: structure, integrity, and data 
manipulation. Data structure defines the form for representing the data. Data integrity 
defines mechanisms for ensuring validity of stored data. Data manipulation provides 


means for manipulating data in database. 


os Data Structure 

All information is stored and presented to users as two-dimensional relations 
(tables). Individual records (or tuples) in relations, equivalent to rows in tables, consist 
of fields (equiv. to columns in tables). The order of records in relations is immaterial. 
Each field (column) refers to an attribute. Attribute signifies the properties of the field, 
such as data type (char, integer, date), size, default value and, most significantly, the 
name of the field. This allows future references by database applications to this 
collection of attribute properties by a single name without knowing how a particular data 
item is stored in database. 

Each tuple is a set of attribute-and-value pairs. The number of tuples in a relation 
is called cardinality. Since the ordering of tuples is immaterial, rows cannot be identified 
by row number. But each tuple can be uniquely identified by a set of attribute-and-value 


pairs, provided that no two tuples in a relation are the same. The minimum set of 
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attributes, whose values uniquely identify each tuple in a relation, is called a (candidate) 
key. If more than one candidate keys in a relation can be identified, one of them Is 
arbitrarily chosen as the primary key of the relation. 
Properties of relations can be summarized as follows: 
e Each relation contains only one record type. 
e ach relation has a fixed number of columns which are uniquely and explicitly 
named. Each attribute name within a relation is also unique. 
e No two rows in a relation are identical. 
e Ineach row, every attribute is atomic, that is, it has only one value set that. 
cannot be further decomposed. Thus, no repeating groups are allowed. 
e Ordering of rows is immaterial. 


e Ordering of columns is immaterial. 


4. Normal Forms 


n theory, no two rows in a relation are identical. Also, within one row, no two 


columns are identical. This notion is easy enough to implement in a database having 
one or very few tables. This is rarely the case in a real-life database. By creating a 
multitude of tables with interrelate information, one can easily be fooled into believing 
that not only each single row in every relation is unique, but also that each attribute- | 
value pair is unique simply by giving the attribute a different name in another (or event 
the same) relation. Then, the same information may be duplicated on several locations, 
which leads to wasted resources and, more importantly, to inconsistent data updates. 


Process of splitting relations with redundant information into two or more relations 
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without the redundancy is called normalization. A normal form is a way of classifying a 
table by its functional dependencies, which means: if | know the value of one attribute, | 
can always determine the value of another. 


There are five main normal forms for relations: 


e First Normal Form 
Each attribute value is atomic. It cannot be a set, or other composite structure. By 


definition of data structure in relational database, each relation meets this criterion. 


e Second Normal Form 


Each relation is in at least the first normal form, and in addition, each non-key 


attribute depends on the entire primary key. 


e Third Normal Form 
Each relation is in at least the second normal form, and in addition, each non-key © 


attribute depends only on the primary key. 


e Fourth Normal Form 


Each relation is at least in the third normal form, and in addition, there is no more 


than one multi-valued data item in the relation. 


e Fifth Normal Form 
A relation meeting the fifth normal criterion cannot be split into two or more tables 


(with each having its own primary key) without loss of information. 


2/ 


5. Data Integrity 

Relational DBMS employs a mechanism which ensures that all data to be stored 
are valid. As a minimum, it needs to ensure that each attribute value is valid, check that 
the set of values in a tuple is unique, and that relationsdesigned to be interrelated have, 


in fact, consistent values within each tuple that relates them. 


a. Primary Key 
Primary key is the only means of addressing a specific tuple within a 


relation. Therefore, in order to be unique, none of the primary key attributes can be null. 


b. Domain 
For some fields it may be useful to determine not only a data type, but 
also a range of permissible values. The following example demonstrateshow declaring 
a domain can limit all possible values of “Location” to just a few, and ensure that valid 
entries for “Weight” are within permissible range: 
CREATE TABLE Sailor( 
ssn char(9) NOT NULL UNIQUE 
Location char(10) CHECK 
| (Location IN (‘Monterey’,’Carmel’,’Pacific Grove’,’Seaside’, 
Del Ray Oaks’,’Salinas’)), 
Weight integer CHECK 
(Weight > 100 AND Weight < 200)): 
SQL-92 allows users to create domains as objects in a schema. Then, columns in tables 


can be declared as types of domain, rather than data types. 
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Cc. Foreign Key and Referential Integrity | 

When all of the valid values in one field of a relation (for example, Rank in 
Admin table) have to exist in a field of another relation (for example, Rank in 
ListOfRanks table), it can be said that the first field references the second and Is, 
therefore, called a foreign key. The field to which it refers to is called its parent key. 
Names of the foreign and the parent key do not have to be the same. The parent key in 
the referenced table has to have either the UNIQUE or the PRIMARY KEY constraint in 
the table’s definition, in order to ensure having unique values. 

Some DBMSs implement referential triggered actions that have update 
effects and delete effects. These specify wnat happens when a parent key value in the 


referenced relation is modified or deleted. There are four options: 


e SET NULL (sets to NULL all foreign keys that reference a parent key if it was 


modified or deleted). 


e SET DEFAULT (same as above, but instead to set the referencing fields to 


null, foreign key values are changed to a preset default value). 


e CASCADE (a change in the parent key value automatically triggers the same 


change in foreign key values). 


e NO ACTION (the foreign value doesn’t change, and if this would violate 


referential integrity, change of the parent key is disallowed). 
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6. Data Definition Language 

Data Definition Language (DDL) commands allow to perform the following tasks: 
e Create, alter, and drop databases and database objects. 

e Grant and revoke access privileges and roles. 

e Establish auditing options. 

e Add comments to data dictionary. 


DLL statements automatically update system catalog tables of DBMS. 


7. Data Manipulation 
As stated earlier, the Data Manipulation Language (DML) is not a language of its 
own. Rather, it is a subset of SQL. DML allows formulation of update queries and select 


queries. Here are four basic DML statements: 


e To adda tuple 


INSERT INTO <relation> VALUES <set of values> ; 


e Toremove a tuple(s) 
DELETE FROM <relation> 


WHERE <condition on attributes>; 


e To modify tuple(s) 
UPDATE SET <set of new values> IN <relation> 


WHERE <condition on attributes>; 
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e To select tuple(s) and join 
SELECT <attributes> 
FROM <relation(s)> 


WHERE <selection criteria>: 


Some aggregate functions that are used with SELECT: 


COUNT, MIN, MAX, AVG, SUM, etc. 
Set operations: 


[NOT] IN, [NOT] EXISTS, CONTAINS (subset check), UNION, INTERSECT, 


MINUS. 


8. Data Control Language 
Data Control language (DCL) consists of statements that control security and 


concurrent access to data in relations. Common DCL commands are: 


e COMMIT (instructs the DBMS to make permanent ail data changes resulting 


from DML statement executed by a transaction). 
e CONNECT (connects user to database). 


e GRANT (assigns access privileges to a database user). 
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e REVOKE (revokes access privileges to database). 


e ROLLBACK (reverses the effect of any DML command executed 


by a transaction, provided that backward log exists and is actively used). 


e LOCK/UNLOCK TABLE (locks/unlocks a table from being accessed 


by other database users). 


D. DATABASE SCHEMA 


Database schema of a distributed database needs to be studied in two contexts: 


e Design of individual databases. 


e Integration of collection of databases into a global schema. 


1. Local Database Schema 

Database schema of individual databases contains logical description of data 
stored in a database. The schema defines the names of data items, their sizes and other 
attributes, and also identifies the relationships among the items. 


Database schema of a local MILDB database is documented in Appendix B. 


2. Global Database Schema 

Local MILDB databases will be queried only by local users. Local users with 
proper privileges, local replicators, will replicate selected data items into the central 
database, where they will become available to global users. Local replicators will also 
replicate certain data from central database into their local MILDB, where it will become 


available to other local users. Data exchange will occur between tables in local MILDBs, 
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and views found in the central database. Figure 1 shows partial global database 


schema. 
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co ACCESS CONTROL 

The goal of this portion of thesis is to establish a firm access control to MILDB 
database and its data. Data are to be displayed to users on need-to-see basis. This 
means that after gaining access to MILDB database via login procedure, users will be 
allowed to view and manipulate only certain columns, and within the scope of these 


columns only those rows, that the user is authorized to see and manipulate. 


1. SQL Access Control 

As mentioned earlier, database access control is implemented by a set of DCL 
commands. Generally speaking, DBMS administrator (a user with the ultimate control 
over any database managed by DBMS) can create other users and give them certain 
privileges. A user, who creates a table, has control over this table (is the table’s owner), 
and can in turn grand various privileges on this table to other users. Privileges are 
authorization identifiers that determine, whether or not a particular user can perform a 
given SQL command from DDL, DML, or DCL set of commands. Privileges are given 
and taken away by GRANT and REVOKE SQL commands. Two basic SQL statements 


can be used: 


GRANT <privilege type> ON <object> TO <user id> ; 


REVOKE <privilege type> ON <object> TO <user id> ; 
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a. SQL Access Control 
As mentioned earlier, database access control is implemented by a set of 
DCL commands. Generally speaking, DBMS administrator (a user with the ultimate 
control over any database managed by DBMS) can create other users and give them 
certain privileges. A user, who creates a table, has control over this table (is the table’s 
owner), and can in turn grand various privileges on this table to other users. Privileges 
are authouzation identifiers that determine, whether ornot a particular user can perform 
a given SQL command from DDL, DML, or DCL set of commands. Privileges are given 
and taken away by GRANT and REVOKE SQL commands. Two basic SQL statements 
can be used: 
GRANT <privilege type> ON <object> ‘TO <user id> ; 
REVOKE <privilege type> ON <object> TO <user id> ; 
To grant and maintain privileges for every individual database user separately would be 
too time consuming and could become too complex. Therefore, DBMSs implement a 
notion of group (or role, in SQL Server 7) to which privileges can be granted. Individual 
users can be added to, or removed from, the group and automatically inherit or lose a 


set of privileges granted to the group. 


b. SQL Server 7 Access Control 

Similar to principles implemented in other DBMSs, a user needs first to 
gain access to DBMS, after which he/she can perform operations on a database 
determined by the role he/she has been assigned. SQL Server 7 also introduces new 


special role, the application role, which will be studied later in this section. 


35 





—C. Security Modes 


To gain access to the SQL Server 7 engine, the user has to pass an 
authentication test. Two authentication methods can be implemented on the SQL Server 
engine in general, and on individual databases: Windows NT Server Authentication 
mode, and Mixed mode. 

When Windows NT Server Authentication mode is applied, the engine checks, 
whether the Windows NT login ID of a user (who must have previously logged in on a 
Windows NT workstation) has been granted access to the database engine. Therefore, 
the user is not challenged by a separate login dialog box when he/she tries to connect to 
database via some interface, because his/her Windows login ID is automatically used. 

When Mixed mode is applied, the user is challenged by a login dialog box. After 
login ID and password (PSW) is submitted, the engine tries first to authenticate the user 
via Windows NT authentication. If the login ID is not in Windows NT authentication 


database, the engine checks its internal user database. 


d. Roles 


Notion of group is in SQL Server 7 replaced by ro/e. Groups are used in 
Windows NT operating system, where they have a function parallel to typical DBMS, but 
applying only to privileges related to the operating system. Entire NT groups can be 
assigned to SQL Server roles. Permissions granted, revoked, or denied to a role 
automatically apply to all users and groups assigned to “play” this role. Roles can be 


further nested. 


Certain roles in SQL Server are predefined: 
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Fixed Server roles allow to perform various tasks on the SQL Server; 
Fixed Database roles allow to perform administrative tasks on individual databases. 

User-Defined role is customized set of privileges that allows its “players” 
to perform various tasks on a single database. User-defined roles are local to each 
database. 

Public Role provides a default (but customizable) set of permissions to a 
user who has not been assigned any other role. 

Application Role allows to restrict access to data based on the application 
through which a user gained access to the database. Regardless of the role that the 
user might have been assigned to in the database, his/her role privileges are temporarily 
suspended for as long as he/she stays connected to the database via the application. 
Both security modes (Windows NT or Mixed) can be used by the application, but no 
“live” users can be associated with this role, since it is the application that has its own 
log ID and PSW. Typically, this log ID and PSW is hidden from users. Application role 
allows great flexibility to database administrators. It may, for example, allow less 
restrictive access to be granted to the application, since actions of its users will be 
controlled by the application, which can prevent them from performing malicious action 
or honest mistake. When connected through some other interface, the same users can 


have much more restrictive permissions (for example, read-only on certain tables). 


e. Permissions 


Login ID allows user to merely connect to SQL Server. A database user ID (same 
as login ID most of the time, but can be different), on the other hand, allows a user to 


access a specific database. But it is the set of permissions that allow a user to access 
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and manipulate objects within the database. Permissions can be assigned to individual 
users, or to roles and groups (meaning, Windows NT groups). SQL Server recognizes 
three different types of permissions: statement, object, and implied. 

e Statement Permissions 

Statement permissions allow users to execute commands typically found in DDL. 
Statement permissions include the following self-explanatory Transact-SQL (see further) 
statements: CREATE DATABASE, CREATE DEFAULT (creates default value), 
CREATE PROCEDURE, CREATE ROLE, CREATE TABLE, CREATE VIEW, BACKUP 
DATABASE, and BACKUP LOG. 

Transact-SQL is Microsoft's version (dialect) of standard SQL-92. It is used for 
communicating between applications and SQL Server. A notable addition to standard 
SQL. found in Transact-SQL, are commands related to creating and manipulating stored 
procedures. | 

e Object Bennigelons 

Object permissions include commands most commonly found in DML. They 
consist of the following Transact-SQL statements: DELETE, EXECUTE, INSERT, 
REFERENCE (ability to link tables), SELECT, UPDATE. 

e Implied Permissions 

Implied permissions are those that users automatically inherit just by the fact that 
they were assigned to a fixed server or database role, or because a particular user is an 
owner of a database object. Implied permissions cannot be assigned. Rather, a 
particular user needs to be included into a build-in fixed group that already has the 


permissions (i.e., database administrators). 
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f. Permission Precedence 


Permissions can not only be granted and revoked, they can also be 
specifically denied. For example: a group of users has been assigned a role with a given 
set of permissions. We don’t want one user from the group to have access to a certain 
view. Instead of removing that particular user from the group (because, possibly, it is 
more convenient to keep him in the group, so that he can perform some other chores 
assigned to this group in a different role), we can explicitly deny this user an access to 
that particular view. 

Generally, the effect of permissions granted to a user is cumulative, with 
the exception of explicit denial of a permission. Denied access to an object overrules any 
permission the user would otherwise had by belonging to a group or role that enjoys that 
permission. If a user was denied access to an object in one group or role, he is 
automatically denied the same access in any other group or role, without the necessity 
to re-apply this denial in these other groups or roles. Permissions can be also denied to 


a group or role, for example, a trouble_makers role. 


g. Ownership Chain 


Whoever creates an object in a database, becomes the database object 
owner of the created object. If one user creates, for example, a table, then creates a 
view based on that table, and then creates a stored procedure that draws from that view, 
he/she is the owner of all three objects in the ownership chain, anon-broken ownership 
chain. If, on the other hand, user1 creates a table (user1 becomes the owner of this 
table), then user2 creates a view from that table (user2 owns the view), and yet another 


user, user3, creates a stored procedure that draws from the view (user3 owns the stored 
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procedure), such chain of ownership is in SQL Server 7 called a broken ownership 
chain. These two distinct cases have some implications: If the chain of ownership is 
non-broken, the owner of these objects needs to grant the permission only to the highest 
object in the chain (the stored procedure) in order to allow another user to operate on it. 
Appropriate permissions (SELECT, etc.) will automatically propagate down the chain. If, 
on the other hand, the chain of ownership is broken, in order to be able to grant 
permissions on the stored procedure, the owner3 of the stored procedure seeds to 
obtain appropriate permissions from owner2 of the view, who in turn needs to obtain 
proper permissions from the owner of the base table, owner1. This situation is to be 
avoided. In order to prevent broken ownership chain, the fixed database role, the 
db owner role, should be used. Anyone assigned to the db_owner role can create, 


manage, and manipulate any object within a database. 


F. USING VIEWS FOR ACCESS CONTROL 

Access to data in a database can be controlled by granting proper permissions 
on selected objects, such as tables and, more recently, even on individual columns. To 
maintain desired set of permissions on every table and even columns could become too 
time consuming complex. The same effect can be achieved in a much simpler way, by 


using views. 
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le Overview 

Views are virtual tables that display selected columns from one or more 
underlying tables. Only the definition of the view is permanently stored in the database. 
The view itself is constructed and populated with data only when itt is called upon. 
Because views are virtual tables, they can be used the same way as the regular tables 
are: they can be used separately, or joined with another table or view; they can be used 
in unions; a view can also serve as a base table for another view. The only limitation is 
that not every view is updatable, as will be investigated in the next paragraph. Views are 
used extensively in the MILDB project. 

Basic syntax for creating a view Is: 

CREATE VIEW <view name> 

AS <query expression> 


[WITH CHECK OPTION]; 


There are few restrictions on the SELECT clause in a view definition. It cannot: 
e include ORDER BY, COMPUTE, or COMPUTE BY clauses. 
e Include INTO keyword. 


e Reference a temporary table. 


Some DBMSs put more restrictions on view's definition. 
Objects, referenced in view definition, must exist before the view can be created. 
In SQL Server, the SELECT clause can be of any complexity and can also include 


functions. If the optional WITH CHECK OPTION is specified, the view has to be 
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updatable. SQL Server also provides WITH ENCRYPTION option, which encrypts the 
CREATE VIEW statement in system tables. Also, in SQL Server, the definition of a view 
can be modified without having to drop and recreate the view, and therefore the 


permissions assigned to the original view are not lost and don’t have to be re- 


established. 


2. Updatable vs. Read - Only Views 


In order for a view to be updatable, every row in the view has to be associated 
with exactly one row in the underlying base table. Naturally, aview which is based on a 
SELECT statement that contains, say, a UNION, does not meet this criterion and cannot 
be updated. View in SQL Server are updatable if: 
e SELECT statement does not contain agregate functions (COUNT, MAX, etc). 
Agregate functions can be used, however, in a subquery in the FROM clause. 
e SELECT statement does not contain GROUP BY, UNION, DISTINCT, or 
TOP. 
e SELECT statement does not contain derived columns, such as those using 
functions, additions, or subtraction operators. 


e FROM clause in the SELECT statement references at least one table. 


A view of a view is updatable only if the source view is also updatable. UPDATE, 
INSERT, and DELETE statements can be executed only on a view that is updatable. 
UPDATE and INSERT statement must be written in such a way, that it modifies data in 


only one of the underlying base tables. 
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3. Using Access Control Table for Filtering Data in Views 


As mentioned earlier, views display selected columns from one or more 
underlying base tables. If we have, for example, a base table named ADMINBASE that 
contains biographical and other data about students from all Units, and we want to 
restrict access to only those data that MILDB users need to see, we can define a view 
named ADMIN that will contain only selected columns from the ADMINBASE table. Such 
view will, after retrieval, contain selected data about all students in ADMINBASE. We 
want to further restrict the view to display only those rows that refer to students from a 
specific Unit, or even specific platoon within that Unit, based on user’s access privileges. 
To achieve that, we can add another condition to the WHERE clause of the SELECT 
statement. Since the ADMINBASE table contains a Unit column, the view definition 
could look like this: 

‘CREATE VIEW admin_a AS 

SELECT Jesitiat selection> 


FROM adminbase 


WHERE Unit = ‘A’ ; 


Hard-coding the Unit's name into the view definition would, however, mandate 
creating separate views for every Unit, and the application would then be required to 
implement a mechanism that could select appropriate view based on user's privileges. 
That would not be practical. We need a single view that will be used by all Units, and still 
display only those rows that a particular user is allowed to see. 

For this purpose, a small access authorization table was created. Itcontains user 


ID of each MILDB user, and Unit and Platoon of personnel that a particular user is 
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allowed to access. Wildcard character (%) can be used as an entry in the Platoon 


column to indicate access to data of all personnel in the Unit. 


Authorization table definition: 


CREATE TABLE mil_auth( 


n_user char(8), 
unit char(1), 
pit char(1)) ; 


Then we can construct a WHERE clause of the ADMIN view, that will include 
only those records from ADMINBASE whose Unit coincides with Unit(s) in table mil_auth 
for a particular n_user. But how can we identify the n_user in the WHERE clause? For 
this purpose we will invoke a special constant, built-in in most DBMSs, that has value 
USER. User is the authorization ID assigned automatically to any user after he/she/it 


logs on. Now we are ready to define view ADMIN as follows: 


CREATE VIEW admin AS 
SELECT <column selection> 
FROM adminbase a 
WHERE a.unit + a.pit IN 
(SELECT ua.unit + ua.plt 
FROM unit_auth ua 


WHERE ua.n_user = USER) ; 
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4. implementation of Views 


a. General 


Every table found in local MILDB database has an equivalent table in the 
central SQL SERVER database, with a suffix ‘base’. Thus, table ADMIN has its 
equivalent table ADMINBASE, APFT table has an equivalent table APFTBASE, and so 
on (with the exception of reference tables that have identical contents and, therefore, 
keep identical names). For each (non-reference) local MILDB table was in SQL Server 
database created a view having the same name and containing the same columns as 
tables in local MILDB, but with a WHERE clause similar to the one described earlier. 


Summary of the system of MILDB tables and views: 


LOCAL MILDB CENTRAL MILDB 

Table Table View 
ADMIN ADMINBASE ADMIN 
APFT APFTBASE | APFT 
BRKS_ACT BRKS_ACTBASE BRKS_ACT 
CC_TRNG CC_TRNGBASE CC_TRNG 
Etc. Etc. — Ete. 


This arrangement has another add-on benefit: Views are virtual tables 
that, when properly defined, can be used just like the base tables. In fact, users may not 
be even aware of whether the object they are accessing is a base table or a view. This 
constitutes additional security mechanism for concealing parts of the database that may 


be confidential or are superfluous to a given user’s needs. Giving the views in the central 
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database the names equivalent to tables in local databases gives the users impression 


that the central database contains tables just to meet the needs of the local MILDB. 


b. Using Views in Joins 
Joins are extensively used in MILDB database and in the interface application. 
Joins allow to retrieve data from two or more tables based on some logical relationship 
between the tables. Joins define how specific values retrieved from onetables are used 
to select the rows from another table by: 
e specifying the column from each table to be used in the join; 
e specifying a logical operator ( =, <=, <>, etc.) to be used when comparing 


values from indicated columns. 


Joins can be specified in the FROM or the WHERE clause. The basic 
SQL-92 syntax for a join in the FROM clause is: 


SELECT <column selection> 


FROM table1 <join type> table2 ON <join condition> ; 


Join type can be INNER, OUTER, or CROSS JOIN. 


The inner join returns rows only when there is at least one row from both 
tables that matches the join condition. For example: 
SELECT a.rank, a.name, c.task_num 
FROM admin a JOIN cc_trng c 


ON (a.ssn = c.ssn) ; 
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Rows from table ADMIN, whose SSN cannot be found in table CC_TRNG, are ignored. 


The outer join, on the other hand, returns all rows from at least one of the 
tables, as long as those rows meet the condition specified in the WHERE or HAVING 
clause. lf there is no matching row in the other table, an empty row is concatenated to 
the row(s) returned from the first table. For example: | 

SELECT a.rank, a,name, c.task_num 
FROM admin a LEFT OUTER JOIN cc_trng c 
ON (a.ssn = c.ssn) ; 
This query will return all students from the ADMIN table. From the CC_TRNG table it will 
return all task_num values for each SSN that exists both in the ADMIN and the 
CC_TRNG table, and add it to the ADMIN portion of each row. For each SSN not found 


in the CC_TRNG table, a NULL (or default) value will be added to such row. 


Cross join returns a Cartesian product of all rows found in both joined 
tables. AS a consequence, it contains a lot of redundant data. It is not used in this 


project. 


As described earlier, a set of views was created in the central database 
to act like virtual tables, equivalent to those found in local MILDB databases. Retrieving 
data from each of these views separately posed no problems. However, when two views 


were joined, we ran into some difficulties. 


4/ 





c. Restrictions 
View ADMIN that contains biographical data provides basic information 
about each student, such as rank, name, ssn, etc. For this reason it is often joined with 
other tables (for example, a table containing training results) in order to give the data 
some meaningful identification to the end user. 
The ADMIN view was defined as: 
CREATE VIEW admin as 
SELECT <column selection> FROM adminbase a 
WHERE EXISTS (SELECT * FROM unit_auth u 
WHERE a.unit + a.plt 


LIKE u.unit + u.plt AND u.n_user = USER) ; 


Now, let’s choose a table that contain some training data (i.e., cc_trng), 
and create a view that will restrict a user to seeing only rows pertinent to his/her Unit and 


Platoon. Five basic view definitions can be formulated: 


A. CREATE VIEW cc_trng AS 
SELECT <column selection> 
FROM cc_trngbase cb, adminbase ab, unit_auth u 
WHERE cb.ssn = ab.ssn 
AND ab.unit + ab.plt LIKE u.unit + u.plt 


AND u.user = USER ; 
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B. CREATE VIEW cc_trng AS 


SELECT <column selection> 
FROM cc_trngbase cb, admin a 


WHERE cb.ssn = a.ssn :‘ 


C. CREATE VIEW cc_trng AS 
SELECT <column selection> 
FROM cc_trngbase cb 
WHERE EXISTS ( SELECT * 
FROM admin a 


WHERE cb.ssn = a.ssn ) ; 


D. CREATE VIEW cc_itrng AS 
SELECT <column selection> 
FROM cc_trngbase cb 
WHERE EXISTS ( SELECT * 
FROM adminbase ab, unit_auth u 
WHERE cb.ssn = ab.ssn 
AND ab.unit + ab.plt LIKE ub.unit+-u.plt 


AND u.user = USER) ; 
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E. CREATE VIEW cc_trng AS 
SELECT <column selection> 
FROM cc_trngbase cb 
WHERE EXISTS (SELECT * 
FROM admin a 


WHERE cb.ssn = a.ssn) ; 


Each of these view definitions have compiled without error, and 


returned correct data when queried by statement: 
SELECT * FROM cc_trng ; 


Problems arose when the following queries were attempted: 
SELECT a.rank, a.name 
FROM admin a LEFT OUTER JOIN cc_trng c 
ON (a.ssn = C.SSn) ; 
SELECT a.rank, a.name | 
FROM admin a RIGHT OUTER JOIN cc_trng c 


ON (a.ssn = c.ssn) ; 
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Results of these queries are summarized for each version of view CC_TRNG in the 


following table: 





RESULT 


Serre SSP COTE OH 
PT scien ent 
cic eee 
LN cei ei 


Data returned Data returned 


Data returned Data returned 





VIEW DEFINITION 












Error message text: The table CC_TRNGBASE is an inner member of the outer-join 


clause. This is not allowed if the table also participates in a regular join clause. 


d. Solution to Restrictions 
SQL SERVER rejects a query in which a table is an inner member of the 
outer-join clause, and also participates in a regular join clause. The source of error 


becomes more apparent when we include the definition of view cc_itrng in the SELECT 


query: 
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SELECT <column selection> 
FROM admin a LEFT OUTER JOIN ( SELECT <column selection> 
FROM cc_trngbase cb, 
adminbase ab, unit_auth u 
WHERE cb.ssn = ab.ssn 
AND ab.unit + ab.pit 
LIKE u.unit + u.plt 
AND u.user = USER) 


ON (cc_trngbase.ssn=a.ssn); | 


When version A and B view cc_trng is applied, the table CC_TRNG 
participates, albeit indirectly via view definition, in the outer join of the FROM clause of 
the main query, and also in a regular join of the WHERE clause of the view definition. In 
versions C, D, and D of the CC_TRNG view, the table CC_TRNGBASE is also a 
member of a regular join, but in the subquery of the view’s definition, which does not 


pose a problem. 


Apparently, views do not always behave as regular tables after all. 
The syntax of their definition may preclude them from participating in joins with other 


tables or views. 


e. Performance Issues 
When used in a join with the ADMIN view, the three versions of the 
CC_TRNG view that returned data did not perform equally well. Performance 


comparison test was conducted for version C, D, and D of the CC_TRNG view during 
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a non-business day, when no other network traffic could affect the speed of data return. 


One version of the view was tested after another. Each set of tests was repeated five 


times. The test query: 


SELECT a.rank, c.ssn, c.task_num, c.task_no, 
c.score, c.d_tested, c,d_tran, c_n_user 
FROM admin a LEFT OUTER JOIN cc_trng c 
ON (a.ssn = C.ssn) ; 
Test results are summarized in the following table: 


Version D Version E 















Time Efficiency 








Time Efficiency Time Efficiency 












[ms] | [ms/record] [ms] [ms/record] [ms] [ms/record] 





[| Dana Mal ined a 4 321 hie Oi 1.752 
44254 1884 47348 2.016 43102 1.835 


3 44414 1.891 47408 2.018 | 43573 1.855 



















44143 1.879 47408 2.018 41299 1.758 


aa 41910 44133 1.878 41299 1.758 





Version E of the CC_TRNG view had consistently the best performance 


and was, therefore, implemented in the database. Good performance of this view can be 


apparently credited to the SELECT * clause in the WHERE EXISTS ( SELECT * ... 


statement, which lets the query optimizer of the DBMS decide which column to use. If 
some of the columns have indexes, the optimizer can use just these indexes to answer 


the query and never actually look at the table itself. The syntax of the version E was 


used in creating the rest of views that draw from base tables. 
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5. Stored Procedures 

a. Overview 

Stored procedures are sets of precompiled SQL statements that perform 
some operations on the database. Stored procedures, like tables and views, are objects. 
They are stored in the database, and require access permissions as any other object. 
Stored procedures, like views, allow to retrieve or modify information in sources to which — 
the user would not normally have access. Such procedures are used in the MILDB 
project. Stored procedures can also be used to perform some database housekeeping 


chores and other operations on a database. 


b. Implementation 

Basic syntax for creating stored procedures: 
CREATE PROCEDURE <procedure name> 

[<input_parm1 dataType>, <input_parm2 dataType>, 

<output_parm dataType OUTPUT>] 

IWITH RECOMPILE] 

AS 


<set of SQL statements> ; 


The RECOMPILE option, used in SQL Server, forces the existing stored 
procedure to be recompiled if significant modifications were done to the original code. 
Some stored procedures used in MILDB are simple, other are more 


involved. Example of a simple procedure is isinAdminBase(), which takes a Social 
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Security Number as input parameter, and returns record_status as OUTPUT. If a given 
SSN exists in ADMINBASE table, the procedure returns a letter indicating the status of 


the record, otherwise it returns “?”: 


CREATE PROCEDURE isInAdminbase( 


@newssn varchar(9), @recstat varchar(1) OUTPUT) AS 


SELECT @recstat = ‘?’ 

SELECT @recstat = rec_stat 
FROM adminbase 
WHERE ssn = @newssn) 


GO 


Stored procedures can be nested. They can call other stored procedures 
or system function, create and delete temporary tables, and so on. Example of a more 
involved stored procedure, used in MILDB, is getSUID(), which takes two input 
parameters ( name of a table, and User ID), and returns as output a combination of 
letters indicating set of basic permissions that the user has on a given table ( S for 
SELECT, U for UPDATE, | for INSERT, and D for DELETE permission). If, for example, 
a user has only SELECT permission on a given table, the procedure will return “S???". 


This stored procedure also calls a system stored procedure USER_NAME: 


CREATE PROCEDURE getSUID( @TABLE_NAME VARCHAR(384), 
@TABLE_USER VARCHAR(384), @TABLE_PERMS VARCHAR(4) OUTPUT) 


AS 
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if ( @TABLE_NAME is null) OR (@TABLE_USER is null) 
begin 
raiserror 20001 ‘Must provide table name and user ID.' 
return 


end 


DECLARE @sel char(1) 
DECLARE @updt char(1) 
DECLARE @insrt char(1) 


DECLARE @dlt char(1) 


SELECT @sel = '?' 
SELECT @updt = '?' 
SELECT @insrt = '?' 


SELECT @dlt = ‘?' 


SELECT @sel = 'S' FROM sysprotects p, sysobjects 0, sysusers u, sysmembers m 
WHERE p.id = 0.id 
AND o.type in ('U’,'V','S') AND object_name(o.id) = @TABLE_NAME 
AND user_name(u.uid) = @TABLE_USER 
AND (u.uid > 0 and u.uid < 16384) 
AND ((p.uid = u.uid) OR (p.uid = m.groupuid AND u.uid = m.memberuid)) 


AND p.action = 193 /*select*/ 


SELECT @updt = 'U' FROM sysprotects p, sysobjects 0, sysusers u, sysmembers m 


WHERE p.id = 0.id 
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AND o.type in ('U','V','S') AND object_name(o.id) = @TABLE_NAME 
AND user_name(u.uid) = @TABLE_USER 

AND (u.uid > 0 and u.uid < 16384) 

AND ((p.uid = u.uid) OR (p.uid = m.groupuid AND u.uid = m.memberuid)) 


AND p.action = 197 /*update*/ 


SELECT @insrt = 'l' FROM sysprotects p, sysobjects 0, sysusers u, sysmembers m 


WHERE p.id = o.id 


AND o.type in (‘U','V','S') AND object_name(o.id) = @TABLE_NAME 
AND user_name(u.uid) = @TABLE_USER 

AND (u.uid > 0 and u.uid < 16384) 

AND ((p.uid = u.uid) OR (p.uid = m.groupuid AND u.uid = m.memberuid)) 


AND p.action = 195 /*insert*/ 


SELECT @dit = 'D' FROM sysprotects p, sysobjects 0, sysusers u, sysmembers m 


WHERE p.id = o.id 


AND o.type in (‘U','V','S') AND object_name(o.id) = @TABLE_NAME 
AND user_name(u.uid) = @TABLE_USER | 

AND (u.uid > 0 and u.uid < 16384) 

AND ((p.uid = u.uid) OR (p.uid = m.groupuid AND u.uid = m.memberuid)) 


AND p.action = 196 /*delete*/ 


SELECT @TABLE_PERMS = @sel + @updt + @insrt + @dlt 
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' The OUTPUT parameter value, returned when getSUID() procedure is 
called from MILDB application, is used to automatically enable/disable the ‘Save’ menu 
selection in the application's main menu. 

Another example of a more complex stored procedure is 
changeViewSsn(), which takes as input parameters an old and new SSN. The procedure 
changes references to the old SSN in selected tables to a new SSN. To accomplish this 
task without violating data referential integrity, the procedure creates a temporary table 
#TEMPVIEWADMIN. This temporary table, which holds temporarily the admin data, is 
automatically dropped at the end of the procedure’s execution. The definition of this 


stored procedure can be found in Appendix B. 


Cc. Access Control 


As mentioned earlier, stored procedures may allow access to objects 
which would otherwise be restricted to a particular user. This capability was utilized in 
the MILDB project. Here is a situation: a system of views, in conjunction with the 
authorization table, allow users to see personnel from only certain Unit, or even a 
platoon within that Unit. When the user needs to add a new service member into the 
database, new SSN must not violate the primary key on SSN in the ADMINBASE table. 
It is easy to check, whether new SSN exists within data viewable to the user, but how 
can the user verify the existence of SSN within records which he/she cannot see? Of 
course, the data integrity mechanism of DBMS would prevent the user from violating the 
primary key constraint in the ADMINBASE table and automatically trigger an error, 
whenever an insertion of a duplicate SSN were attempted. But we want to avoid 


undescriptive system-triggered messages, and we also want to be able to propose the 
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user some gracious alternatives. For example, activate a previously deactivated record. 
The stored procedure islnAdminbase(), described safes was designed specifically for 
this purpose. This stored procedure has access to the entire ADMINBASE table, and 
can verify the existence of any given SSN in it, while the user does not. The user is 


given only the EXECUTE permission on the stored procedure. 


d. Executing Stored Procedures 
Executing a stored procedure can be a one, or two step process. 
Database interfaces, non-native to a given DBMS, need to declare a stored procedure, 


before they can execute it. Here is an example of such stored procedure declaration: 


DECLARE <alias_procedure_name> PROCEDURE FOR 
<procedure_name> 
[parm1 = valuei, parm2 = value2, 


parm3 = value3 OUTPUT] ; 


Then, the procedure can be executed by a statement: 


EXECUTE <alias_procedure_name> ; 


The same stored procedure can be executed from SQL Server native interface 


by a single statement: 


EXECUTE <procedure_name> [<parm1, parm2, @parm3 OUTPUT] ; 
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IV. CLIENT SERVER ARCHITECTURE 


Client server architecture emerged as a solution to the limitations of file sharing 
architectures. Using DBMS, client can query a database residing on server by means of 
SQL or remote procedure calls. Two basic types of arrangement of client/server 


architecture are possible: two-tier, and multi-tier model. 


A. TWO-TIER MODEL 

In two-tier model, the presentation and business logic of the application is 
deployed on the client computer, and the database management services, along with the 
database, are located on the server. This is a good solution when the number of users 
does not exceed 100 concurrent users. After that, the server may become burdened by 
keeping too many active connection sen and performance may start to suffer. 
Disadvantage of this model includes, besides the number of users limitation, necessity 
of complex data access control, heavy network traffic, and the necessity to deploy the 


entire application, along with supporting run-time DLLs, on every user’s workstation. 


B. MULTI-TIER MODEL 

In this model, a middle tier is added between the user system and the database 
management server environment. The middle tier can serve as application server, 
message server, or processing monitor. In a typical three-tier model, for example, only 


the application’s presentation logic is installed on client workstation, while the business 
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logic runs on the application server (the middie tier), and the DBMS with the database 
resides on another server. The three-tier architecture has demonstrated improved 
performances over the two-tier model, especially with a large number of users (in the 
thousands). Also, by centralizing the business logic on the application server, greater 


access control to sensitive information can be exercised. 


C. SELECTION OF CLIENT SERVER MODEL 

The MILDB database is going to be accessed by users from a single network 
domain. There will be far less than 100 users at any given time. Some MILDB users will 
be connected to the network only occasionally, but they will continue to access their data 
on their local MILDB databases, and will require the business logic of the MILDB 
application to be installed on their workstations. 


Two-tier client/server model will be implemented. 
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V. DEVELOPING DATABASE APPLICATION IN POWERBUILDER 7 


A. OVERVIEW 

PowerBuilder is an object-oriented apeleation development tool for building 
multitier applications that interact with databases. PowerBuilder applications consist of a 
user interface, and application processing logic. PowerBuilder applications are event 
driven. Users control application’s behavior by the action they take. PowerBuilder 
provides a rich set of tools for accessing databases managed by variety of DBMSs. The 
application processing logic is formulated in a proprietary fourth-generation language, 
called PowerScript, which also permits queries written in SQL to be embedded in it. 


PowerBuilder for Windows is going to be applied in this project. 


B. POWERBUILDER OBJECTS AND CONTROLS 


Objects are the basic building blocks of any PowerBuilder application. They are: 


° Application 

Application object is the entry point into an application. It defines application-leve! 
behavior, such as what processes should occur when the application starts and 
closes. For example, if scripted accordingly, the open event of the application object 


will open the introductory window. 
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e Window 

Window is the primary interface between the user and the application. A window 
consists of properties, that define the window’s appearance and behavior, events 
triggered by user actions, and controls which are objects placed on a window (i.e., 


buttons, edit fields, text labels, dataWindow control, and others). Controls have a set 


of properties and events of their own. 


e DataWindow Object 

This object, fundamental to a typical PowerBuilder application, is used to retrieve and 
manipulate data from a database, or some other data store. This object also handles 
the way data is presented to the user. DataWindow object can not only contain data 
retrieved from database, it can also include computed fields that derive their values 
from the retrieved data. Pictures and graphs can also be tied directly to the retrieved 
data. DataWindow ee does not display directly in a window. In order to be able to 
display it on the window, one has to create a DataWindow control, and then 


associate this contro! with desired DataWindow object. - 


e Menu 


Menus are lists of items that a user can select from a menu bar assigned to the 
active window. Functionality of PowerBuilder’s menus is equivalent to those found in 


other window applications. 
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e Global Functions 


Global functions are self-contained pieces of programming code that can be called 
from any object within the PowerBuilder application. Other type of functions, object- 
level functions, can be called only within the scope of a particular object. Global and 


object-level functions can be user-defined, or build-in by PowerBuilder. 


e Queries 
This objet is a SQL statement, saved with a name identifier so that it can be used 


repeatedly anywhere in the application. 


e Structure 
Like in any other programming language, a PowerBuilder structure as a collection of 
variables .of the same, or different, data types. Similar to functions, they can have 


global, or object-level scope. 


e User Object 

PowerBuilder has two types of user objects 

Visual User Object (Reusable set of controls that has a consistent behavior. The 
Student Locator, found on most of the windows in MILDB application, is an example 
of such visual user object.) 

Class User Object (Reusable non-visual user object serving as a processing module. 
A standard class user object of type transaction is used in MILDB application to 


declare and execute stored procedures. ) 
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Custom Class User Objects (Non-visual objects that serve as building blocks in 
distributed PowerBuilder application. They provide various services, based on 


functions and variables defined in them.) 


e Library 
Library is a file (PBL file) in which PowerBuilder objects are saved. A PowerBuilder 


application can during its compilation draw objects from one or more PowerBuilder 


libraries. 


e Project 
Serves for creation of application executables and DLLs. Project object is used only 
in the developer's environment. It contains information about resource libraries, the 


type of executable, and other compilation options. 


C. POWERSCRIPT LANGUAGE 


1. Overview 

PowerScript is a 4GL PowerBuilder language. PowerBuilder programming code, . 
called script, consists of PowerScript commands, functions. and statements that are 
executed in response to events. Object-oriented capabilities of the PowerScript allow 
partitioning the business logic of an application into well-organized, reusable classes. 


PowerScript fully supports inheritance, encapsulation, and polymorphism. 
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2. Classes, Properties, and Methods 


e Classes 

Standard PowerScript classes include windows, menus, controls, and user 
classes. These are the foundation of visual objects. Non-visual objects are 
instantiations of standard class user objects (inherited from PowerBuilder system 
objects, such as Transaction, Message, or Error), or custom class user objects 
(inherited from PowerBuilder nonVisualObject — class). PowerBuilder’s 


nonVisualObject class allows to define an object class from scratch. 


e Properties 
Properties are defined by object variables and instance variables. Instance 
variables can be declared as public, protected, or private. This provides control how 


other objects’ script can access them 


e Methods 

Methods include events and functions. A list of events, typical for any given 
object, is readily available for coding in the PowerBuilder programming interface. 
Additional events can be also included from PowerBuilder’s own library of events, or 
from Windows events. PowerScript provides an extensive list of functions that can be 
used to act on various components of PowerBuilder application. Programmer can 
also declare and define his/her own functions in order to fulfil some specific ease 
Arguments can be passed to events and functions be value, by reference, or as 
read-only. In PowerBuilder 7, object events can be overriden in the chain of 


inheritance, and functions can be overloaded. 
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3. Global Variables and Functions 
PowerBuilder implements several build-in global variables and functions. A 
programmer can also declare his/her own variables and functions which have global 


scope, and can be accessed from any script within the application. 


4, Garbage Collection 
The PowerBuilder garbage collection mechanism automatically checks memory, 


and destroys any unreferenced or orphaned objects. 


D. COMMUNICATING WITH DBMS 

Most of the communication with DBMS takes place viamethods which are built-in 
PowerBuilder objects. For example, when user invokes an update() method of 
DataWindow, PowerBuilder generates and submits to DBMS all necessary SQL 
statements. But programmer can also formulate his/her own SQL statements, and 
embed them in PowerScript code. Embedded SQL statements have to be concluded 
with a semicolon (;). All SQL statements, embedded in scripts or dynamically generated 


by PowerBuilder, are executed by means of a transaction object. 


1. Transaction Object 
Transaction object is a special non-visual object that serves as an intermediary 


between PowerScript and the DBMS. The transaction object contains parameters that 
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PowerBuilder application uses to connect to a database. Every PowerBuilder application 
automatically creates a global default transaction object, named SQLCA (SQL 
Communication Area). This, or another transaction object, explicitly declared and 
created by script, can be used to connect, communicate with, or disconnect from 
database. 

Before a connection can take place, at least some transaction object properties 
have to be set: 

e DBMS (Indicates the DBMS that manages the database to be connected. 


Can be set to “ODBC” .) 


e Database (Name of the database to which the application will connect. Can 
be the name of ODBC data source (DSN), established in the ODBC 


interface.) 


e DBParm (Contains DBMS-specific connection parameters, such as 


AutoCommit, Lock, DSN, ServerName, etc.) 
Other parameters may be needed in order to establish a connection with 
database, such as Log ID, PSW, server name, and others, but they may be provided by 
DSN, or may be requested by the DBMS dialog box at the time of connection. 


Connection to database is requested by statement: 


CONNECT [using <transaction_object>] ; 
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If no transaction object is specified in the statement, the SQLCA is used by default. 


Other transaction management statements are: 


e COMMIT; (makes permanent all changes made to the database) 


e ROLLBACK; (all modifications to the database, performed by current 


transaction, are undone) 
e DISCONNECT; (disconnects from database) 


Application can connect to more than one database at a time. Each connection 
needs to be managed by a separate transaction object. Such arrangement is applied in 
MILDB, when data are synchronized between sea MILDB and the central database. 

Example of establishing a multiple database connection: 

CONNECT using <sourceTransObj> ; 


CONNECT using <destinationTransObject> ; 


2. Transaction Object and Stored Procedures 

Stored procedures can be executed by SQL statement, embedded in the script. 
This, however, will not work if the stored procedure returns an OUTPUT parameter, or 
when a stored procedure which contains a DLL statement is called. For this purpose, a 
customized version of the standard class user object of type transaction has to be used. 
Once such user object is created by means of PowerBuilder Object Wizard, stored 


procedures can be declared as external functions, or external subroutines, for that user 
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object. If the stored procedure has a return value, it must be declared as a function. If 
the stored procedure returns nothing or void, it must be declared as a subroutine. In both 
cases, a RPCFUNC keyword has to be used in the declaration. 


Examples of stored procedures declared in a user object, applied in MILDB: 


Subroutine getSUID( string table_name, string table_user, ref string table_perms) 


RPCFUNC alias for “mil.getsuid” 


Function int sp_setapprole( string roleanme, string password, script encrypt) 


RPCFUNC alias for “dbo.sp_setapprole” 


The second declaration is for a built-in SQL Server stored procedure which 
activates permissions associated with an application role. This stored procedure 
contains a DLL statement, and must be executed outside the scope of a transaction. To 
achieve that, this procedure must not only be declared as a function in a customized 
transaction object, but the autoCommit property of the transaction object must be set to 
TRUE before the procedure is called. 

Once the stored procedures are declared in a customized transaction object, 
they can be executed from the application script by statement: 


<trans_object_name>.<procedure_alias_name( [parm1, parm2, ....] ; 


3. DBMS Interfaces 


PowerBuilder application can connect to a database through a standard 


database interface (i.e, ODBC, JDBC, or OLE DB), or through a native database 
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interface. A standard database interface communicates with the database via standard- 
compliant driver ( ODBC, or JDBC connection), or data provider (OLE DB connection). 
The standard-compliant driver or data provider translate abstract function calls, defined 
in standard API, into calls understood by a specific DBMS. A native database interface 
communicates with DBMS via a direct connection to database, using a native API 


library. 


a. ODBC Interface © 
Open Database Connectivity (ODBC) is a standard application 
programming interface (developed by Microsoft, is API which allows an application to 
access a variety of DBMSs. An ODBC-compliant driver, appropriate for a given DBMS, 
has to be installed on user’s workstation. SQL is used for communication with the 
database. The ODBC specifies: 
e A library of ODBC function calls for connecting to the database, executing 
SQL statements, and retrieving results. 
e Astandard way to connect and log on to a DBMS. 
e SQL syntax. 
e Standard representation for data types. 


e Standard set of error codes. 


PowerBuilder provides a set of ODBC drivers for the most common DBMSs, 
such as Sybase, Oracle, SQL Server, and others. ODBC drivers can be also obtained 


directly from DBMS vendor. Since the ODBC driver for Microsoft Access is readily 
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available on user's workstation, and only the SQL Server driver will have to be installed, 
the ODBC interface will be used in this project for communicating with databases. 
When accessing an ODBC data source from a PowerBuilder application, the 


connection goes through several layers, before reaching the data source: 


e Application (calls ODBC functions). 

° ODBC Driver Manager (installs, loads, and unloads drivers for the 
application). 

e Driver (processes ODBC function calls). 


e Data Source (stores and manages data in a database). 


b. OLE DB Interface 

OLE DB, a component of Microsoft’s Data Access Component software, 
is a standard API developed by Microsoft. It allows an application to access a variety of 
data for which OLE DB data provider exists. Data can be stored in a variety of forms: 
indexed-sequential files, spreadsheets, e-mail, personal databases, or full-fledged 
DBMS. An OLE DB data provider is a dynamic link library (DLL) that implements function 
calls. An application invokes the OLE DB data provider to access a particular data 
source. Some OLE DB providers are shipped with PowerBuilder, other can be obtained 


directly from a data source vendor. 


73 





Cc Native Database Interface 
A native database provides a direct native connection to a particular 


DBMS. It implements its own interface DLL, which communicates with the specific 


database through a vendor-specific API. 


E; BUILDING THE MILDB APPLICATION 
1. Application Architecture 


The MILDB application consists of one application object, and multitude of 
dataWindow objects, global functions, menu objects, user objects, pipeline objects, and 
windows. All these epee are stored in a single PowerBuilder library file, named 
mil_0799.pb!. The architecture of the MILDB application is shown on Figure 2. The list of 
objects in the application is extensive. Some objects serve only one task, such as 
dataWindow objects that retrieve and display canned reports. Other objects, such as 
user objects Si menus, are used repeatedly throughout the application. Even though 
every object shown in Figure 2 was developed and Is fully functional, documenting each 
of them would exceed the scope of this thesis. Only several major components of MILDB 
application are documented in order to demonstrate how the application was developed, 


and how it functions. 


2. Application Object 


The application object, named Millshell, serves as the entry point into MILDB 


application. Through this object, global variables are declared and initialized, database 
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Figure 2. MILDB Application Architecture 


15 





connection is established, and the introductory window is opened. Application object is 
non-visual. The following code shows the script of the Millshell application object: 


//***APPLICATION OBJECT 
//Declare global external function 


function int getwindowsdirectory(ref string buff, int sz) 
LIBRARY "kernel" 


//Global variables 


string globAppname //application name 

string globVersion //application version 

string fetch ssn //student SSN 

string company JPJUAIE- ANGLCator 

string expPath //physical path of export file 


//APPLICATION OPEN EVENT 


//**Company 

//set in script of w_frame 

//put "" (empty) to install troop command menu/toolbar 
company = "" 


//**Export path 
expPath = "C:\MILX\export.txt" 


//**Application Name & Version 
globAppname = "MILGB - Military Database" 
globVersion = "7.0" + company 


//open splash windows 
open (w_splash) 


//setup ODBC 
sqlca.dbms = "ODBC" 
sqlica.DbParm = "ConnectString='DSN=milstu'” 


SOLCA.AutoCommit = True 


fp f** = CONNECTION . 
//Try the central MILSTU as default first 


cCOnneCct, 


//wnen connection fails, try connection to local MILDB 


if sqlca.sqicode < 0 then 
//Try connection to local datbase MILX 


16 











SOLCA.Database = "mildb" 


sqica.DbParm = "ConnectString='DSN=MILX'; "& 
+ 'Time=" "'  hhemmess: t's Tohsg 
+ "delimitidentifier='NO';" 
connect; 
else 


//get logID of current user 
select distinct n_user into :sqica.userID 
from mii.unit auth 
where n. USer = user; 
end if 


1f sglca.sqicode < 0 then 
messageBox ("DATABASE CONNECT", "Could not connect to database") 


HALT 
end if 


//open MDI frame 
open(w_ frame) 


//close splash window 
close(w_ splash) 


3. DataWindow Objects 


DataWindow objects are used to retrieve and manipulate data from database. 
Individual data fields (columns) of dataWindows can be setup as updatable, or read- 
only. Values, retrieved from database, can processed be further in dataWindow’s 
calculated fields. Data can be displayed in various formats, and be arranged within a 
dataWindow as needed. Figure 3 through Figure 6 show examples of dataWindow 
objects used for retrieving, displaying, and manipulating student data. SQL statements 


for populating each dataWindow is also included. 
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Figure 3. DataWindow d_adminnew 


SQL statement for d_adminnew: 


SELECT mil.admin.dob , 
mil.admin.d_arrival , 
mil.admin.d_rank , 
mil.admin.pay grd , 
mil.admin.race , 
mil.admin.ssn , 
Mil.admin.WG.-tran: + 
mil.admin.n_user , 
mil.admin.bped , 
mil.admin.basd , 
mil.admin.ets , 
mil.admin.d unit , 
mil.admin.mar_ stat , 
mil.admin.mealcard , 
mil.admin.service , 
mil.admin.branch , 
mii.admin.pay code , 

‘mil.admin.d_dlab , 
Mil.<admin.q dlab , 
mil.admin.pmos , 
mil.admin.ult_mos , 


f 


mil.admin.sm_status 


Til .~admin:«i1c¢. 7 
mil.admin.lic 2 
Mmil.admin.asl y 
mil.admin.sex , 


f 


, 
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mil.admin.unit , 
mil.admin.n student , 
mil.admin.rank , 
Mid seaming age, 
mil.admin.plt , 
mil.admin.class , 
mil.admin.d depart, 
mil.admin.placeofbirtn 
FROM mil.admin 
WHERE { mil.admin.ssn = :ssn )}) 


~ 


Fi DataWindow - d_admin : es . 
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Figure 4. DataWindow w_admin 


SQL statement for dataWindow d_admin: 


SELECT mil. admin.dob, 
mil.admin.d arrival, 
mil.admin.d_rank, 
mil.admin.pay_ grd, 
mil.admin.race, 
mil.admin.ssn, 
mil.admin.d_tran, 
mil.admin.n_user, 
mil.admin.bped, 
mil.admin.basd, 
mil.admin.ets, 
mil.admin.d_unit, 
mil.admin.mar_ stat, 
mil.admin.mealcard, 
mil.admin.service, 
mil.admin.brancn, 
mil.admin.pay code, 
mil.admin.d_dlab, 
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mil.admin.gq dlab, 
mil.admin.pmos, 
mil.admin.ult_ mos, 
mil.admin.sm_status, 
mMil.admin.lic 1, 
mil;,eadminslic 2, 
mil.admin.gsi, 
mil.admin.sex, 
mil.admin.unit, 
mil.admin.q age, 
mil.admin.placeofbirth 
FROM mil.admin 


WHERE (mil.admin.ssn :ssn) 
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Figure 5. DataWindow d_regadmin1 and d_regadmin 


SQL statement for d_regadmin1 and d_regadmin: 


SELECT mil.admin.class, 
mil.admin.dob, 
mil.admin.d arrival, 
mil.admin.d_rank, 
mil.admin.n student, 
mil.admin.pay grd, 
mil.admin.pit, 
mil.admin.race, 
mil.admin.rank, 
miil.admin.sex, 
mil.admin.ssn, 
mil.admin.d tran, 
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mil.admin.n_user, 
Ma LvOoprice Ore, 
Mil,office.<dty phon 
FROM {0} mil.admin LEFT OUTER JOIN mil.office 
. ON mil.admin.ssn = mil.office.ssn} 
WHERE mil.admin.ssn = :ssn 
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Figure 6. DataWindow d_form90 


SQL statement for d_form90: 


SELECT ‘mil.form90.educ ivi, 
Mid. Lomrmg0. yrs Svc; 
mil.form90.motivate, 
mil.form90.natv_eng, 
mil.form90.natv_ oth, 
mil.form90.prr_lang, 
mil.form90.yr trained, 
mil. form90.prr prot, 
mil.form90.source, 
mil.form90.prr dlpt, 
mid. Formg0.pre expr, 
mil.form90.ssn, 
mil.form90.d_tran, 
mil.form90.n_ user, 
mil<tormg0.prrilangz, 
mil.form90.prr_lang3, 
Mid~form90.prr protz, 
mih.TOormg0.prEe. profs:, 
mal formoO.prr .expr2, 
Mil.formg0.prr -expr3; 
Mit. FOrmO. pre dlptZ, 
mad. torm90:..pre- alors 

FROM mil. form90 
WHERE ( ( mil.form90.ssn = :ssn ) ) 
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4. Global Functions 


There are several global functions designed to perform certain operations 
repeatedly throughout the application. The following code shows the declaration, 


purpose, and script of MILDB global functions: 


//***GLOBAL FUNCTIONS 


//PARAMETERS: string dateText - military date 
//RETURNS: 1 if success, or -1 if invalid date 
//PURPOSE: converts & modifies referenced date 
7] from military format to civilian 


integer civdate ( ref string datetext ) 


//accepts reference to string containing military date 

//converts & modifies referenced date from military format to civilian 
//Civilian date format: MM/DD/YY 

//Military date format: YYMMDD 

//returns 1 if success, or -1 if invalid date 


//parameter: date dateText 


//Local variables 
date milDate //date in military format 


mildate = date (dateText) 

if year(milDate) = 1900 then 
string newDate, yr , mo, dy 
newDate = dateText 
yr = left(newDate, 2) 


mo mid(newDate, 3, 2) 
dy mid(newDate, 5) 


i 


if isNumber(yr) then 
if integer(yr) >= 50 then 
yr = "ZO" + yx 
else 
yo = Le Vn 
end if 


newDate — mo. "/™ ody + o7" + ye 
milDate = date (newDate) 


if year(milDate) = 1900 then 
messageBox("DATE", & 


82 











"Enter date in one of the following formats: " & 
+ "YYMMDD , or MM/DD/YY, or other format used by Windows.", & 
Exclamation!) 


return -l 


else 
dateText = newDate 
end if 
else | 
messageBox("DATE”", "Enter date in one of the following formats: " 
& 
+ "YYMMDD , or MM/DD/YY, or other format used by Windows.", & 
Exclamation!) 
return =—1 
end if 
end if | 
return 1 
//PARAMETERS: string decIn - decimal number in string format 
//RETURNS: string str - decimal number in string format 
//PURPOSE: formats a decimal number to contain at least 
es one leading, and two trailing zeros 


string de2 ( string decin ) 


//Local variables | 
string str //formated decimal string 


Str = Fight (" "+ string(dec(decin), "##0.00"),6) 
return str 


//PARAMETERS: date dob - date of birth 

// date ageDate - date when age is calculated 
//RETURNS: integer - age in years 

//PURPOSE: formats a decimal number to contain at least 


integer getage ( date dob, date agedate ) 


return ( daysAfter( toCiv( dob), toCiv( ageDate) ) /365) 


//PRRAMETERS: window sourceWindow - owner of dataWindows 
iJ datawindow dwArry[{] - array of dataWindows 
//RETURNS: integer - number of dataWindows 
//PURPOSE: Counts and returns the number of 

// all dataWindows on the referenced window 


integer getdwlist( readonly window sourcewindow, ref datawindow 
dwarry[] ) 


//Finds all dataWindow controls in Window 


//and puts references to them into array passed as argument 
//returns number of dataWindow controls 
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//Local variables 


dataWindow dwList[] //temp array of dataWindows 
int dwCnt //dataWindow counter 
re) a: //step counter 


//initialize local variable 
aQwCnt = 0 


//prowse through all objects in the window 
//when the object is dataWindow, put it in dwList[] 
for ii = 1 to upperBound( sourceWindow.control[]) _ 
if sourceWindow.control[ii].typeOf() = dataWindow! then 


dwCnt++ 
dwList[dwCnt] = sourceWindow.control [ii] 


end if 
next 


//assign temp arry to referenced dataWindow array 
dwArry = dwList 


return dwCnt 


//PARAMETERS: userobject sourceobj - owner of dataWindows 


iy. datawindow dwArry[] - array of dataWindows 
//RETURNS: integer - number of dataWindows 
//PURPOSE: Counts and returns the number of 

// all dataWindows on the referenced user object 
int getdwlistofuo(readonly userobject sourceob)j, ref datawindow 
dwarry[] ) 


//Finds all dataWindow controls in source userObject 
//and puts references to them into array passed.as argument 
//ceturns number of dataWindow controls 


//Local variables 


dataWindow dwList[] //temp array of dataWindows 
int dwCnt //dataWindow counter 

ine. et: //step counter 

dwCnt = 0 


//browse through all objects in the user object 
//wnen the object is dataWindow, put it in dwList[] 
for ii = 1 to upperBound( sourceObj.control[]) 
if sourceObj.control[ii]:typeOf() = dataWindow! then 
dwCntt++ 
dwList[dwCnt] = sourceObj.control [ii] 
end if 
next 
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//assign temp arry to referenced dataWindow array 
dwArry = dwList 


return dwCnt 


//PARAMETERS: date civDate ~ date in civilian format 
//RETURN: string milDate ~ date in military format 
/ / PURPOSE: converts civDate to string containing 

as military date format of civDate 


string mildate( date civDate) 


//takes argument: date civDate, passed by value 
//converts civDate to string containing military date format of civDate 
//returns string milDate 


string milDate //date in miltary format 
if year( civDate) = 2000 then 

milDate = string( civDate, "YYYYMMDD") 
else 

milDate = string( civDate, "YYMMDD") 
end if 


return miiDate 


//PARAMETERS: decimal xVal ~ decimal number 
//RETURN: 

//PURPOSE: 

dec roundToQuarter( decimal xVal) 


//Receives parameter DECIMAL xVal 
//rounds passed value to the nearest quarter 


//Local variable 
dec{2} roundVal 


roundVal.= (int(xVal / 0.25))*0.25 
if (xVal - roundVal) >= 0.125 then 
roundVal += 0.25 


end if 


return roundVal 


//PARAMETERS: any milDate - date in variable of any data type 
//RETURN: any ( or NULL value if empty parm submited) 
//PURPOSE: Converts date or string into 

ae Civilian date format mm/dd/yyyy 


any toCiv( any mildate ) 
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//T£ parameter is date, function returns date (in variable of type 


any) 
//Ilf parameter is string, function returns string 


//Local variables 


string civDateStrng //civilian date string 
string parmType //parameter type 
string yr, mo, dy //year, month, day 
date civDate //civilian date 


//get parameter type 
parmType = ClassName( milDate) 


//cast the date 
civDateStrng = trim( string( milDate) ) 


if civDateStrng = "" then 
setNull( civDateStrng) 
setNull( civDate) 


else 
if isDate( civDateStrng) then 


civDate = date( string( mildate, "mm/dd/yyyy") ) 


else 
//two right-most digits => day 
dy = right( civDateStrng, 2) 


//first two of the four right-most digits => month 
mo = right( civDateStrng, 4) 
mo left( mo, 2) 


//remaining digits, 
//after disregading four right-most digits, => year 
yr = left( civDateStrng, ( len( civDateStrng) - 4)) 


civDateStrng = mo + "/" + dy + "/" + yr 


if isDate( civDateStrng) then 
civdate = date( civDateStrng) 


end if 
end if. 
end if 
if parmiype =. "string ‘then 
return civDatesStrng 
end if 


return civDate 
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//PARAMETERS: any milDate - date in variable of any data type 


// any actionparm ~- indicates option chosen 

a by user in messageBox 

//RETURN: any ( or NULL value if empty parm submited) 

//PURPOSE: Converts date or string into 

TF Civilian date format mm/dd/yyyy 

any toCivwBox ( any mildate, ref any actionparm ) 

//If parameter is date, function returns date (in varuable of type 
any) 


//T£ parameter is string, function returns string 


//Local variables 


string civDateStrng //civilian date string 

string parmType //parameter type 

string yr, mo, dy //year, month, day 

int. DOxRErn //indicates option chosen by user in messageBox 
date civDate //civilian date 


//get the type of parameter 
parmType = ClassName( milDate) 


civDateStrng = string( milDate) 


//initialize the message to be displayed 
msg = "Enter date in one of the following formats:~n~n"s& 


+ “YYYYMMDD, or YYMMDD, or MM/DD/YYYY, or MM/DD/YY.~n"& 

+ "Use leading 0 (zero) for days and months below 10 when” & 

+ “ using the military date format.~n~n"& 

+ "EXAMPLES: 20010430, 010430, 4/30/2001, 4/30/l~n~n"& 

+ "Tf the year is displayed as two digits, the century is “& 

+ “determined as follows:~n"é 

+ "Year is between ~tDefault Century Digits ~CEXAMPLE~n"& 

+ "00 and 49 =tZO0-tstet 204 9en"s 

+ "SO" and 99 ~CL9-t~t-tl976~n-n"<s 

+ "Include the century (e.g. 3/27/1944, 19440327) when you “& 

+ “want to override "& 

+ "the default interpretation of a two-digit year, "& 

+ “or not certain how the date will be interpreted by the 
program." 


if isDate( civDateStrng) then 


civDate = date( string( mildate, "mm/dd/yyyy") ) 
setNull( msg) 


else 
//two right-most digits => day 
dy-= Tight ( civDatestrng,: 2) 


//first two of the four right-most digits => month 
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mo = right( civDateStrng, 4) 
mo = Leftt mo, :2) 


//remaining digits, after disregading four right-most digits, => 


year 


vr = left( civDateStrng, ( Len( ‘civDateStrng). = -4)) 


ciyvDateStrng = mo -"/" + dy + "7" + yz 


if isDate( civDateStrng) then 
Civdate = date( civDateStrng) 
setNull( msg) 
end: af 
end if 


if isNull( msg) then 


//indicate conversion success 
boxRtrn = 0 


else 
choose case lower( string( actionParm) ) 


case "retrycancel" 
//indicate user selection in dialog box 
boxRtrn = messageBox( "DATE", msg, exclamation!, retryCancel!) 


case else 
//indicate user selection in dialog box 


boxRtrn = messageBox( "DATE", msg, exclamation!) — 


end choose 
end if 


actionParm = string({ boxRtrn) 


if parmType = "String" then 
return civDatestrng 
end if 


return civDate 


5. Menus 


There are two menu types in the MILDB application. The first, such as menu 
m_MDiframe, is intended for a permanent display on user's interface. They continuously 


provide the menu’s functionality to the user. The second type, such as menu 
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m_adminObject, is instantiated and provides its list of commands in the form of a popup 


menu only when needed. 


Each of these menu types have an ancestor version, which serves MILDB users 
who have access to data from only a single Unit, and a descendant version, which 
provides additional functionality to global users who can access records from several 


Units. The descendant menu names carry an extension “_tc’, for “troop command’. 

a. Menu m_MDI 

This menu is displayed permanently along with the MDI (Multiple Display 
Interface) frame, and provides lists of commands in three major groups: 


e File (includes commands, such as Save, Print, Close Sheet, Exit, etc.). 


® Folder (opens the initial window for distinct MILDB operations, such as 
editing student administrative data, physical training-related data, and 


dormitory room assignment). 
e Help (opens user help, and the ‘About’ window ). 
Figure 7 on the following page shows the structure of menu m_MDI, and its descendant 


menu m_MDI_tc. 


The following code shows an example of scripts that drive both menus: 
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//***MENU m MDIframe 


MENU m file.m save 


window activeSheet /f/active window 
commandButton currButton //command button 
int L //step counter 


activeSheet = w_ frame.GetActiveSheet () 


if isValid(activeSheet) then 
for i = 1 to upperBound(activeSheet.control[]) 
if activeSheet.control[ij}.typeOf() = commandButton! then 
currButton = activeSheet.control[i] 
if string(currButton.classname()) = "cb save" then 
triggerEvent (currButton, clicked!) 
return 
end if 
end if 
next 
end if 


MENU m file.m_ close 
window activeSheet //active window 
activeSheet = w_frame.GetActiveSheet () 


if isValid(activeSheet) then 
close (activeSheet) 
if isValid(w_frame.GetActiveSheet()) = false then 
w_frame.MDI_1.resize(0,0) 
end if 
else 
//openSheet ( ) 
w frame.MDI_1.resize(0,0) 
end if 
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Figure 7. Menu m_MDI and m_MDI_tc 
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===] m_mdiframe_tc 





&Save [Ctl+S] 


KX &Close [Ctrl 4] 


= ED &Print [Ctrl+P] 


Print Setup ... 
Export as Text [Ctrl+E] 


E&xit [Ctrl+x] 


F&older 


= #& Administration [F5] 
ee Physical Training {F6] 
~ £P Barrack Utilization (F7] 


&Window 
&Tile 
&Layer 
& Cascade 


&Help 
&Contents [F1] 
About 





F&older 
MH Administration [F5] 


EK Physical Training [FS] 
- £8 Barrack Utilization (F7] 


Utilities 


Company 


CoA 
CoB 
CoC 
CoD 
CoE 
CoF 
CoG 
Co HQ 
ALL 


& Window 
&Tile 
&Layer 
&£ Cascade 


&Help 
&Contents [F1] 
About 


MENU me Pte de eetae 

w base currWind //active window 

currWind = w_ frame .GetActiveSheet () 

if isValid( currWind) then 
currWind.printReport () 


return 
end if 


messageBox("Print", "No report to print.") 


MENU m file.m_exportastext 


window activeSheet //factive window 
commandButton currButton 7//OOCT On 
int. & //local counter 


activeSheet = w_frame.GetActiveSheet () 


if isValid(activeSheet) then 
for i= 1 to upperBound(activeSheet.control{]}) 
if activeSheet.control[i].typeOf() = commandButton! then 
currButton = activeSheet.control[i] 
if string(currButton.classname()) = "cb export" then 
triggerEvent (currButton, clicked!) 
return 
end. ag 
end if 
next 
end if 


MENU m file.m_ exit 


close (parentWindow) 


MENU m folder.m admin 


setPointer(hourGlass!)} 
OpenSheet (w_admin, w_frame, l, layered!) 


MENU m folder.m_physicaltraining 
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set Pointer (hourGlass!) 
openSheet (w_apft_wc, w frame, 1, layered!) 


MENU m folder.m barrackbunkassignment 


setPointer (hourGlass!) 
openSheet (w_hotel_ acc, w_frame, 1, layered!) 


b. Menu m_adminObject 

Menu m_adminObject is not permanently displayed. It contains 
commands for opening windows that serve to accomplish a specific task, such as to 
create a new student record, to record a pregnancy counseling session, or to display a 
name roster. They appear as popup menus when needed. Names of menus and 
submenus were chosen to also indicate their function. Figures 8 and 9 show the 
structure of menu m_adminObject, and its descendant menu m_adminObject_tc. 


The following code shows an example of script that drives the menus: 


//***MENU ADMINOBJECT 


MENU m_ inprocessing.m ptl 


int success //open window success/fail 
success = openSheet (w_admin, w_frame, 1, layered!) 
Lf Success. = 1. then 

w_admin.setW_admin( this.text) 

Lf: fetch. ssn-<> "then | 

w aedmin.ferchData () 

end if 

end if 
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“&# Menu - m_adminobject inherited from menu 
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Figure 8. Menu m_adminObject 
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"si Menu - m_adminobject_tc inherited from m_adminobject 
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Figure 9. Menu m_adminObject_tc 
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MENU m_inprocessing.m pt2 


int success //open window success/fail 
success = openSheet (w_admin, w_frame, 1, layered!) 
if success = 1 then 

w_admin.setW_admin ( this, text) 

if fetch_ssn <> "" then 

w_ admin.fetchData() 

end if 

end if 


MENU m_ inprocessing.m pt3 
int success //open window success/fail 
success = openSheet (w_admin, w_frame, 1, layered!) 
if success = 1 then 
w admin.setW_admin( this.text) 
if fetch_ssn <> "" then 
w_admin.fetchData() 


end if 
end if 


6. User Objects 

Two major user objects are used throughout the MILDB application: Locator 
(named o_locate) which displays list of personnel and triggers retrieval of data pertinent 
to a given person, and Admin user object (named o_adminObject) which serves as 
visual interface for displaying popup menus that are related to a specific administrative 


task. 
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a. Locator o_locate 

This object retrieves and displays a list of platoons and names of all 
personnel assigned to a single Unit. Platoon names are displayed on the left side of the 
Locator in dataWindow dw_plt, one platoon name per row. Names of the personnel are 
displayed on the right side of the Locator, in dataWindow dw_loco, one name per row. 
When user clicks on name of a platoon, list of personnel assigned to that platoon 
appears in dw_loco. When checkBox ‘Show All’, which appears at the bottom of the 
Locator, is selected, all names of personnel in the Unit appear in alphabetical order in 
dw_loco. When user clicks a person’s name in dw loco, that person’s SSN is submitted 


to the currently active window for further processing. Figure 10 shows the Locator. 


4g User Object - o_locate inherited from userobject 





Figure 10. Locator o_locate 
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The following code shows script of events of the object o_locate, and of the 


controls contained in it: 


//***USER OBJECT O_LOCATE 
//IS USED ENYWHERE WHERE LIST OF STUDENTS IN UNIT IS NEEDED 


//INSTANCE VARIABLES 
m adminObject newMenu //instance of menu with supporting functions 
long oldRow = 0 //saves previous row indicator 


//OBJECT EVENTS 


//EVENT CONSTRUCTOR 
string comp 


//instantiate menu 
newMenu = create m_adminObject 


comp = upper(left (company, 1)) 


if comp = "8" or comp = "" then 
comp = "ALL" 

end if 

st _2.text = "Company " + comp 


cbx 1.checked = false 
//set transaction object for dataWindows 
dw plt.SetTransObject (sqica) 


dw_loco.setTransObject (sqlca) 


//retrieve students 
dw plt.retrieve (company) 


//EVENT DESTRUCTOR 
dw plt.reset () 
dw_loco.reset () 


destroy newMenu 


//OBJECT FUNCTIONS 


//PARAMETERS: string ssn 


// string filterStrng - dataWindow filter definition 
//RETURN: none 

f7PURPOSE: Finds record for given SSN in dw_loco, 

// highlights proper platoon in dw_plt, and name in dw_loco 
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showLine( string SSN, readonly string filterStrng) 


//Local variables 
string pit 
String Bucket //temp 


long pltRow 


long locoRow 


//platoon 


//row number in dw plt 
//row number in dw _plt 


//lock display 
dw plt.setRedraw( false) 
dw _loco.setRedraw( false) 


//unselect any platoon row 
dw plt.selectRow( 0, false) 
dw_loco.selectRow( 0, false) 


//reset filter for names display 


aw l1oco,.S6tFiiter( : "") 
OW LOCO. FLL ver.() 


/JEine platoon -for’ ssn 


Bucket = 
locoRow = 


"ssn = aw, FEU + ssn + 


reese re 


dw loco. find ( Bucket, 


if LocoRow > O then 


1, 


10000) 


plt = dw.loco.getItemString( locoRow, 

Bucket = “plt =] e"° + ple + Nat" 

pltRow = dw_plt.find( Bucket, 1, 1000) 

//display records for platoon 

Bucket. = "pit = a Ss PLE rae 

if (not isNull( filterStrng)) and 
Bucket += " and " + filterStrng 

end if 


dw loco.setFilter( Bucket) 
dw LOCco;ri ter) 


jfEinG ssw in. tilreresa dw Loco 


Bucket 


locoRow 


//nighlight rows for appropriate platoon and ssn 
dw plt.selectRow( pltRow, true) 


"osn — =~» ae ssn + 


tee 


dw _loco.find( Bucket, 





Toute ai ) 


( filterStrng <> "") 


1, 10000) 


dw _loco.selectRow( locoRow, true) 


else 


//ssn not 


FILTER! ) 
end if 


found => move all rows to filter buffer 
dw loco.RowsMove(1, dw_loco.rowCount(), PRIMARY!, dw_loco, 10000, 
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//anlock display 
dw plt.setRedraw( true) 
dw _loco.setRedraw( true) 


return 


//PARAMETERS: long currRow - current row indicator 


//RETURN: none 
/ /PURPOSE: Submits SSN to a window for further processing 


submitToForm( readonly long currRow) 


//Local variables 
string currWindowNm //name of current window 


if currRow > 0 then 
fetch ssn = dw_loco.getItemString( currRow, 2) 
sle_ssn.text = fetch_ssn 

else 
return 

end if 


currWindowNm = w frame.getActiveSheet ().classname() 
choose case currWindowNm 


case "w_mildata”" 
w mildata.fetchData() 


case "w_ history" 
w history.fetchData() 


case "w_admin" 
w_ admin. fetchData () 


case "w_weightcontrol" 
w_weightcontrol.fetchData() 


case "w apft”" 
w_apft.fetchData() 


Gase "wo protite” 
w protile.fetchData |) 


case "w wthist" 
w _wthist.fetchData () 


case "w_apfthist" 
w_apfthist.fetchData() 


case else 
//Ao nothing 
end choose 
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this.borderStyle = styleBox! 


//EVENTS OF CONTROLS 


//CHECK BOX cbx_1 

//EVENT CLICKED 

//When the checkBox state 'Checked' => show ALL personnel in dw loco 
//otherwise => show personnel by platoon 

dw_loco.setRedraw(false) 


if this.checked = false then 
dw_loco.setFilter("plt = ~"-?~" ") 
Qw_ loco. Filter () 

else 
dw plt.selectrow(0, false) 


1f dw_loco.fiiteredCount() = 0 then 
dw_loco.retrieve (company) 
end if 


dw loco.setFilter("isNumber(ssn)") 
dw _loco.Filter() 
dw_loco.selectrow(0, false) 
dw_loco.selectrow(l, true) 
dw_loco.setFocus () 


end if 


dw_loco.setRedraw(true) 


//DATAWINDOW dw_loco 

//CONTAINS NAME AND SSN OF STUDENTS 

//EVENT CLICKED 

//When the checkBox state 'Checked' => show ALL personnel in dw_loco 
//otherwise => show personnel by platoon 

dw _loco.setRedraw(false) 


if this.checked = false then 
Gw. LOCOsSetri iter ("ple = a" 2e" (") 
aw. loco. Filter () 

else 
dw plt.selectrow(0, false) 


if dw_loco.filteredCount() = 0 then 
dw_loco.retrieve (company) 


end if 


dw _loco.setFilter("isNumber(ssn)") 
dw loco.Filter() 
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dw _loco.selectrow(0, false) 
dw loco.selectrow(1, true) 
dw_loco.setFocus () 


end if 


dw loco. setRedraw (true) 


//EVENT RIGHTBUTTOTDOWN 

//When the checkBox state 'Checked' => show ALL personnel in dw_loco 
//otherwise => show personnel by platoon 7 
dw_loco.setRedraw(false) 


if this.checked = false then 
dw loco.setFilter ("plt = ~"-?~" ™) 
dw_loco.Filter() 


else | 
dw plt.selectrow(0, false) 


if dw_loco.filteredCount() = 0 then 
dw loco. retrieve (company) 
end if 


dw loco.setFilter ("isNumber (ssn) ") 
dw l6oco. Filter) 
dw_loco.selectrow(0, false) 

dw loco.selectrow(1l, true) 
dw_loco.setFocus () 


end if 


dw_loco.setRedraw (true) 


//EVENT KEYDOWN 
//Action to take when user presses certain keys 


long currRow 


//keyEnter 
if keyDown( keyEnter!) then 
//start processing 
submitToForm( currRow) 
//keyControl 
elseif keyDown( keyControl!) then 
currRow = getSelectedRow( 0) 
//keyDownArrow 
if keyDown( keyDownArrow!) then 
//select the row above 
this.selectRow( 0, false) 
this.selectRow( currRow + 1, true) 
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submitToForm({ currRow +1 ) 

end if 

//keyUpArrow 

if keyDown( keyUpArrow!) then 
//select the row below 
this.selectRow( 0, false) 
this.selectRow( currRow - 1, true) 
submitToForm( currRow - 1 ) 

end if 


end if 


//EVENT MOUSEMOVE 





//highlight rows as the user moves the mouse over rows 


string rowStrng //cow identifier 


long pos //position of character 


rowStrng = this.getObjectAtPointer() 
pos = Post rowStrng;, "<tc", 2) 

pos += 1 

rowStrng = mid( rowStrng, pos) 

pos = long( rowStrng) 


if pos > 0 then 
if pos <> oldRow then 
This.SelectRow(0, FALSE) 
this.selectRow( pos, true) 
oldRow = pos 
end if 
end if 


//DATAWINDOW dw plt 
//CONTAINS PLATOON NAMES 
//EVENT CLICKED 


string platoon //name of platoon 

string currWindowNm //name of current window 

string Sex //gender 

string dwFilter //filter definition for dataWindow 


//nightlight current row 

if row > 0 then 
this.selectrow(0, false) 
this.selectrow( row, true) 

end if 


if row > O then 


cox 1.checked = false 
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platoon = trim( this.getitemstring( row, 1)) 


1£f isNull(platoon) then 
platoon = "$" 
end if 


currWindowNm = lower( w_frame.getActiveSheet ().classname() ) 


//show only Males, or Females, or ALL 
choose case currWindowNm 


case "w weightcontrol" 
//get only Male or Female 
if w_weightControl.tab wc.selectedTab = 1 then 


//sex = "mM" 

QwFilter = "plt = '" + platoon + "" and sex = ~"M~" " 
else 

//sex = rae 

dwhilter.= "pit = "" + platoon + “" and sex =e "F<" © 
end if 


case else 
dwFilter = as oOo = thoy platoon 4 wre 


end choose 
dw_loco.setRedraw (false) 


if (dw_loco.rowCount() > 0) OR (dw_loco.filteredCount() > 0) then 
//ceset the filter, before new filter will be applied 
//this will ALL personnel back into dw_loco 
aw: Locouset Filter ("): 
dw lo0coO.Filter () 
else 
//i£ personnel not retrieved yet, do it 
dw _loco.retrieve (company) 
end. 24 . 


//set and apply new filter 
dw_loco.setFilter (dwFilter) 
aw Loce.t2alter() 


dw_loco.selectRow({1, true) 
dw_loco.setRedraw (true) 


dw: LOco«Seurocus |) 


end if 
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b. User Object o_adminObject 


User object o_admin appears permanently on windows that provide the 
interface for fulfilling some administrative tasks, such as entering new service member 
into the database, updating person’s administrative data, outprocessing a student, 
deactivating his/her record, etc. The purpose of this object is to display the choice of 
several the major administrative task options available to the user, and to display a 
popup menu offering further options once a specific task is selected (clicked). Afterbeing 
selected, the background color of a label that displays an administrative task changes, 
and remains highlighted even when a popup menu is dismissed and the user proceeds 
to work with displayed data. This provides the user with persisting visual clue about the 
nature of the operation that he/she is performing. Replacing this user object with a 
simple menu would not provide such visual clue. Figure 11 shows the design of object 
o_adminObject and menus that popup when its label, indicating an administrative task, 


is clicked. 
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4ag User Object - o_adminobject inherited from userobject 
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Figure 11. User Object o_adminObject 
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Cc; User Object u_storedProc 


This is a non-visual user object that is used for database transactions, 
and also as an interface for executing stored procedures. How such object can be 
created was described in Section C. Figure 12 shows the external functions and 


subroutines declared in u_storedProc. 


4a User Object - u_storedproc inherited from transaction 


| Seript - getselupdtinsdel ( string table_name, string table_user, ref string table_perms } returns {none} 


| (Functions) getselupdtinsdel ( string table_name, string table_user, ref string table_perms ] returns (none} 


(New Function} 

getselupdtinsdel ( string table_name, string table_user, ref string table_perms } returns (none) 
getsuid ( string table_name, string table_user, ref string table_perms ) returns (none) 
isinadminbase { sting newssn, ref string recstat ) returns (none) 

sp_setapprole { string rolename, string password, string encrypt ] returns integer 





Figure 12. User Object u_storedProc 


1: Windows 


All windows in the MILDB application are hosted by a window of type MDI. Based 
on user’s action, other windows are opened as sheets within the MDI frame. To 
demonstrate the process of designing and scripting MILDB windows, the MDI frame and 


one major window, which implement inheritance, is documented in this thesis. 
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a. MDI Frame w_frame 
This window hosts other windows, called sheets, of MILDB application. 
Associated with this window is menu m_MDIlframe(_tc) described earlier in this Section. 


Figure 13 shows the design of window w_frame. 


P:Military Database 





Figure 13. Window w_frame 
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The following code shows script of the opening event of w_frame: 


//***WINDOW W_FRAME 
//WINDOW OPEN EVENT 


//Local variables 


string errStrng //error string 

string Bucket //tcemp 

long rowCnt //cow count 

dataStore ds tempStore //non-visual dataStore 


//instantiate dataStore 
ds_tempStore = CREATE dataStore 


//sql syntax for dataStore 
//select Unit(s) and Platoon(s) that USER can see 
Bucket = "select unit from mil.v_cansee”" 


Bucket = sqlca.SyntaxFromSOL( Bucket, "", errStrnq) 


//create dataStore and retrieve data 
ds_tempStore.create( Bucket, errStrng) 
ds tempStore.setTransObject( sqlca) 
rowCnt = ds_tempStore. retrieve () 


choose case rowCnt 
case 0Q 


messageBox( "MILDB OPEN", "Can't see any information.") 


//quit application 
HALT 


case is > 3 
//show troop command menu 
//intialize global variable to "A" 
company = "A" 
this.changeMenu(m_mdiframe_ tc) 
Bucket = "ALL COMPANY DATABASE" 


case else 
//set global variable 
company = ds_tempStore.getItemString( 1, "unit") 
//set Unit-level menu 
this.changeMenu (m_mdiframe) 
Bucket = "COMPANY " + company + " DATABASE". 


end choose 
//set the window title 


this.title = Bucket 
WwW. Spilash.bringlolop, = true 
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b. Window w_base 


This window is an ancestor of numerous other windows found in MILDB. 
It contains a single object, user object o_locate, described earlier in this section. In this 
window are declared several window-level functions whose scripts are defined, or 


extended, in descendant windows. Figure 14 shows the design of window w_base. 






.° |Locate: Show AW 


- ; Name [ _ 





Figure 14. Window w_base 
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The following code shows scripts of w_base events and functions: 


//***WINDOW W_BASE 


//DECLARE INSTANCE VARIABLES 


datawindow dwList[] //list of dataWindow controls 
int closeCode //O=can, l=cdnnot close window 
boolean saveEnabled //stores the state of menulItem 'Save' 


//WINDOW EVENTS 


//WINDOW OPEN EVENT 
Eni eRy Vy //local counters 


//call window function (get number of data windows) 
yy = getDwList( this, dwList) 


if yy > 0 then 


//nide all dataWindows 
for xx = 1 to yy 

dwList [xx] .hide() 
next 


//coreate menu for dataWindow utilities 
if isValid( dwUtilMenu) then 
//do nothing 
else 
dwUtilMenu = CREATE m_dwchanges 
end if 
end if 


//WINDOW ACTIVATE EVENT 
//restore the last state of 'Save' menu in MDI frame 
w frame.menulD.item[1].item[1].enabled = saveEnabled 


//WINDOW DEACTIVATE EVENT 
//save the last state of 'Save' menu in MDI frame 
saveEnabled = w frame.menulD.item[1].item[1] .enabled 


//KEY DOW EVENT 

//set focus to locator 

if keyDown( keyControl!) then 
uo_1.dw_loco.setFocus () 

end if 
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//MOUSE MOVE EVENT | 
if uo 1.borderStyle <> styleBox! then 
uo 1,porderstyle: = stylebox: 
uo: l~brang?Tolop = false 


if isValid( getFocus()) then 
if getFocus().className() = "dw loco" then 
dwList [upperBound (dwList)j.setFocus () 
end if 
end if 
end if 


//CLOSE QUERY EVENT 


//Initialize instance variable 
closeCode = 0 //allow closing 


//Local variables 


int msgCode //return code from messageBox 
int dwCnt //row count 
Barc: as //step counter 


long modifiedCnt //number of modified rows 
modifiedCnt = 0 


//check if 'Save' enabled in MDI menu 

et w frame.menuID.item[1].item[1].enabled = false then 
return 0O 

end if 


//check for data change 
dwCnt = upperBound(dwList[]) 
for i= 1 to dwCnt 
dwList{f{i].acceptText () 
modifiedCnt += dwList[i].modifiedCount () 


next 


if modifiedCnt > 0 then 


msgCode = messageBox (this.title, "Do you want to save changes" & 


+ " to current record?", & 
Question!, YesNoCancel!) 


CHOOSE CASE msgCode 
CASE. 2 
closeCode = 0 //close after saving 
saveData () 
CASE 2 
closeCode = 0 //close without saving 
CASE ELSE 
closeCode = 1 //don't close 
END CHOOSE 
end if 
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//allows / aborts closure of window 
return closeCode 


//WINDOW FUNCTIONS 


//PRRAMETERS: none 

//RETURN: (none) 

//PURPOSE: Enable/disable SAVE menu based on permissions 
setSaveMenu () a; 


//Local variables 
string updtTable //table name 


string permList //permission string SUID 

//S - Save, U - Update, I - insert, D - delete 
string Bucket //temp 
int xx //step counter 


if SOLCA.Database = "mildb" then 
//update possible 
//First menu item in 1st submenu is 'Save' 
w_frame.menulD.item[1].item[1].enable() 
return 

end if 


//get permissions from all dataWindows except dw_l 
permList = "" 


for xx = 1 to upperBound( dwList[]) 
if dwList[ xx]).dataObject <> "" then 
updtTable = dwList[ xx] .Object.dataWindow.Table.updateTable 


if updtTable <> "" then . 
updtTable = mid( updtTable, pos( updtTable, ".") + 1) 
Bucket = "????" 


sqica.getSUID( updtTable, sqlca.userID, Bucket) 
permList += Bucket 
end if 
end if 
next 


//now set the menu 

if pos( permList, "U") > O then 
//update possible 
//First menu item in lst submenu is 'Save' 
w frame.menulID.item[1].item[1] .enable() 


elise 
//update restricted 
//First menu item in lst submenu is 'Save' 
w Trame.menulD.irem[ li .atem! 1) <dusable{) 
end if 
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return 


//PARAMETERS: none 


//RETURN: (none) 
//PURPOSE: Retrieve records 
fetchData () 


//do nothing 
//declared here, but will be extended in descendent windows 


//PARAMETERS: none 


//RETURN: (none) 
//PURPOSE: Print report 
printReport () 


//do nothing 
//declared here, but will be extended in descendent windows 


//PARAMETERS: none 

//RETURN: (none) 

//PURPOSE: Update dataWindows 
savedata () 


//do nothing | 
//declared here, but will be extended in descendent windows 


//putton cb print 
//fevent clicked () 
parent.printReport () 


c. Window w_base_admin 


This window is a descendant of w_base. It adds user object 
o adminObject to objects already contained in the ancestor window. The window's Open 
event is extended to include some initial setup of its user objects. This window is an 
immediate ancestor of windows handling administrative data processing of MILDB. 


Figure 15 shows the design of w_base_admin. 
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Figure 3. Window w_base_admin 


The following code shows scripts contained in w_admin_base: 


//WINDOW W_BASE ADMIN 
//INHERITED FROM W_BASE 
//WINDOW EVENTS 


//WINDOW OPEN EVENT 
//EXTENDS ANCESTOR SCRIPT 


//LOCAL VARIABLES 


long lghtGray //RGB 
string lghtGrayStrng //RGB string 


115 





//count instances of admin windows 
adminCnt ++ 


//initialize adminMenu shared variable 
if not isValid( adminMenu) then 
adminMenu = create m_adminObject_tc 


end if 


lghtGray = RGB(192, 192, 192) 
ightGrayStrng = string( lghtGray) 


//set bkgr color of tabs in action menu 
uo_adminmenu.st_inProcessing.backColor = lghtGray //light gray 
uo_adminmenu.st_outProcessing.backColor = lghtGray //light gray 


uo_adminmenu.st_indiviInfo.backColor = ightGray //light gray 
uo _adminmenu.st_indivHistory.backColor = lghtGray //light gray 
uo _adminmenu.st_viewer.backColor = lghtGray //light gray 


uo_adminmenu.st_inProcessing.tag = lIghtGrayStrng //light gray 
uo_adminmenu.st_outProcessing.tag = lghtGrayStrng //light gray 


uo _adminmenu.st_indivinfo.tag = lghtGrayStrng //light gray 
uo_adminmenu.st_indivHistory.tag = lghtGrayStrng //light gray 
uo_adminmenu.st_viewer.tag = lghtGraystrng //light gray 


//WINDOW RESIZE EVENT 
//set position of Locator, based on window/screen size 


uo 1.X = this.width - uo_l.width - 50 


d. Window w_admin 


This window is a descendant of window w_base_admin. In addition to 
objects it has inherited from its ancestors, it also includes dataWindow controls for data 
retrieval and manipulation, and a button for creating new records. Several window-level 
functions, declared in its ancestor windows, are defined here, or are just extended. New 
window-level functions, performing the initial setup of the window, are added. Figure 16 


shows the design of the window, and an example of data display (all data are fictional). 


116 








“t ALL COMPANY DATABASE 
FO atc LL ok) 1 ae = eee 


M6Rx OFM azanenoers & 
‘3 Pt1 Admin. BPED. Spouse. Quarters. ete. 











Rank Pit Class 2x Box 
[SPC FAZMIIO MARK Paos7ess32, [6 [21so1KPo0297 «= | | Company A 
DOB: {720818 Service: ia BPED: 960814 OLAB Score: h30 
Age: 27 Pay Grade: £4 BASD: (60814 DLAB Date: 60710 
Marital St: 5 Branch: PMI DOR: 60814 | 
Sex: pMos: b8G Arrived DLI: 661018 
Race: UMOS: [886 Arrived Unit: 561018 
BirthPlace: SM Stet: | ETS: 000813 
MealCard: 82701065 ast: WE 
Number 
of Depnds: Spouse's Name: | 
Housing: 
7 Locate: Show All [1 


Address: | Phone: | 
Zip: | City: | State: | Consent: [~ Name | 





Figure 16. Window w_admin 


The following code shows scripts of window w-admin events, and window-level 


functions. 


//***WINDOW W_ADMIN 
//DESCENDANT OF W_BASE ADMIN 


//DECLARE ADDITIONAL INSTANCE VARIABLES 
//none 
//WINDOW EVENTS 


//WINDOW OPEN EVENT 
//EXTENDS ANCESTOR SCRIPT 
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//Local variables 
string Bucket //cemp 


//set window title 
this.title = " Inprocessing " 


//find if user can inser new soldier 
Bucket = space (4) 
sqica.getSUID( "admin", sqlca.userID, Bucket) 
if pos( Bucket, "I") > 0 then 
cb_add.show() 
else 
cb. add. hide () 
end if 


//set labels in 'tab' user object 
uo_adminmenu.st_inProcessing.backColor = RGB(255, 255, 255) //white 
uo _adminmenu.st_inProcessing.tag = string(RGB(255, 255, 255)) //white 


//WINDOW FUNCTIONS 


//EXTENDS ENCESTOR FUNCTION 
fetchData () 


int XX //STEP COUNTER 


//check for modification of previously retrieved data 
//triggerEvent( closeQuery! ) 


if closeCode = 1 then 
//user doesn't want to move to next record 
return 

end if 


XxX = setW_admin( this.title) 

if xx <> 0 then 
//no admin form selected yet 
return 

end if 


setRedraw( false) 


//reset dataWindow 

for xx = 1 to upperBound( dwList) 
dwList [xx].reset () 

next 


//retrieve data 

if fetch ssn <> "" then 
dw l.réetrieve( fetch ssn) 
dw _2.retrieve( fetch_ssn) 
dw 3.retrieve( fetch_ssn) 
dw 4.retrieve{ fetch_ssn) 
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else 


return 
end if 
if dw_1.rowCount() = 1 then 
primeNewRows ( fetch_ssn) 
else 


messageBox( "ADMIN DATA", "No recors retrieved.") 
end if 


dw_1.show() 
dw _2.show() 
dw_3.show() 
dw_ 4.show() 
dw_5.hide() 
dw_6.hide () 


if dw z2.dataObject = "d_ form90" then 
dw 6.retrieve( fetch ssn) 
dw_6.show() 

end 1.5 


setRedraw( true) 


return 


//EXTENDS ANCESTOR SCRIPT 
printReport () 


setpointer (hourglass!) 


af Ow l.rowCount(). < 1 then 
messageBox ("PRINT REPORT", "Nothing to print.") 
return 

end if 


string Bucket //temp 
string equals, dashes, blnk //text containers 


int job //print job 

int Cie. 2p: la) 0S, Cab, 64, 25... £6 //orint andents 
tl = 300 

t2a = 1200 

t2 = 2400 

£3 = 5000 

t3b = 4500 

t4 = 6500 

t5 = 6700 

//t6 = 6000 
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if (dw _2.dataObject = "d_admin") OR (dw_2.dataObject = "d_adminnew") 
then 


job = printopen() 


printDéefineFont( job, 1, "Arial", —10,. 400, defaults; « 
anyfont!, false, false) 

printDefineFont( job, 2, "Arial", -10, 700, default!,& 
anyfont!, false, false) 








— ee VY het ee A TU 


lee he eS ES eG CS ES SS Ci A A ve Se eS SS SS SS Ss ee ee dere 
SS SS SSS LS Te ee ee ee i ee ee re ree re ee ee ee ee ee ee ee ee ee ee ee ee ee ee 


//***header 

printSetFont{ job, 1) 

print ( job; 2500, "*** FOR OFFICIAL. USE ONLY -> PRIVACY ACT DATA 
ial 

Print. 70D, ~“") 

pring’ Jeb, 7") 

print (job, 3200, "PERSONAL DATA REPORT") 

Point. joo, -"”) 

PLING ljOb,- "5 

pPrinc(yob, -"") 

Printtjoby. """) 
print (! job, 0, equals) 
printSetFont( job, 2) 


if (dw _2.dataObject = "d_admin") then 


Bucket = dw_l1.getitemstring(1, "rank") 

if isNull (Bucket) then; Bucket = ""; end if 
prink(j ob; tl, "Rank; “" + “Bucket, C2Za: >) 
Bucket = dw 1.getitemstring({l, ‘nc scudent’’) 
if isNull (Bucket) then; Bucket = ""; end if 
print(job, "Name: " + Bucket, t3b ) 

Bucket = dw_l.getitemstring(1, "ssnadmin") 
if isNull (Bucket) then; Bucket = ""; end if 


print()ob;. "SSN: -” + Bucket; -2*tzZ + 1000) 
Bucket. = dw l.getitemstring(l, "plt") 


if isNull (Bucket) then; Bucket = ""; end if 
prine(joo, “PLES * + Bucket, cs) 
Bucket = dw_l.getitemstring(1, "class") 
if isNull (Bucket) then; Bucket = ""; end if 
Drint(job; “Class: + -bucket:) 
praneljoo,.-"") : 

else 
Bucket = dw _2.getitemstring{1, "“rank") 
if isNull (Bucket) then; Bucket = ""; end if 
print (job; tl, “Rank: “-“pBueket,..©2a.) 
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Bucket = dw 2.qetitemstring (1). “n-student") 


if asNulli (Bucket) then; Bucket = ""; end if 
print(job, "Name: " + Bucket, t3b ) 

Bucket = dw_2.getitemstring(1, "ssntarget"™)’ 
if isNull (Bucket) then; Bucket = ""; end if 


print(job;- "SSN. "+ Bucket, 2*t2 + 1000) 
BUCKEt = (Gw2. Get vemst ring (1, Tole) 


if isNull (Bucket) then; Bucket = ""; end if 
print(job, "PLT: " + Bucket, t4) 
Bucket = dw 2ogetitemstrang( 2, "“class”™) 
if isNull (Bucket) then; Bucket = ""; end if 
print(job, "Class: " + Bucket) 
Prine (Fob, "") 
print (Geb, "") 
end if - 


printSetFont( job, 1) 
print( job, 0, equals) 


1f (dw_2.dataObject = "d_ adminnew") then 
printSetFont( job, 2) 
end if 
“PEine (Goby; ") 
PEEING COD, 


//LINEL 


Bucket = string(date(dw_2.getitemDateTime(1, "dob"))) 
if isNull (Bucket) then; Bucket = blnk; end if 


princ(j ob; til, "DOB: " + Bucket, tz.) 
Bucket: =.dw Z2.géetatemstring (i, “service™) 
if isNull (Bucket) then; Bucket = blnk; end if 


Print (job, “Services + Bucket,. t3b -) 

Bucket = string (date(dw_ 2.getitemDateTime(1, "bped"))) 
if isNull (Bucket) then; Bucket = blink; end if 

print (16b; "“BPED: "+ Bucket, -t4-) 

Bucket = string(date(dw_2.getitemDateTime(1, "d_dlab”™))) 
if isNull (Bucket) then; Bucket = bink; end if 
print(job, "DLAB Date: " + Bucket) 

Print (job, "") 


//LINE2 


Bucket = string (dw-2.getitemNumber(1], “age™).) 

if asNull (Bucket) then; Bucket = blnk; end if 
print (job; cL, “Age: " + Bucket, t2: 4 

Bucket = dw_2.getitemstring(1l, "pay grd") 

if isNull (Bucket) then; Bucket = blink; end if 
print(job, "Pay Grade: " + Bucket, t3b )} 

Bucket = string(date(dw_2.getitemDateTime(1, "basd"))) 
if isNull (Bucket) then; Bucket = blink; end if 
pranc(job; "BASD: “ + Bucket;.-t4..) 

Bucket = string(dw_2.getitemNumber({1, "q diab") ) 
if isNull (Bucket) then; Bucket = blnk; end if 
print(job, "DLAB Score: “ + Bucket ) 

PrEne( ob, ) 
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//LINE4 | 
Bucket = dw_2.getitemstring(1, "mar_stat") 
if isNull (Bucket) then; Bucket = blink; end if 
print (job, tl, "Marital St.: "+ Bucket, t2 ) 
Bucket = dw _2.getitemstring(1, "branch") 
if isNull (Bucket) then; Bucket = blink; end if 
print(job, "Branch: " + Bucket, t3b } 
Bucket = string(date(dw_2.getitemDateTime(1, "d_rank"))) 
if isNull (Bucket) then; Bucket = blnk; end if 
print(job,; "DOR: * = Bucket) : 
Printijoo, VY") 


//LINES 
Bucket = dw 2.getitemstring({1l, “sex") 
if isNull(Bucket) then; Bucket = blnk; end if 
print'( job, tl, “Sex: " # Bucket; t2°) 
Bucket = dw 2.getitemstring(l, "pmos") 
if isNull (Bucket) then; Bucket = blink; end if 
print (job, “PMOS?" + Bucket, -t35 ) 
Bucket = string (date (dw_2.getitemDateTime (1, "el. red Ped.) )-) 
if isNull (Bucket) then; Bucket = blnk; end if 
pFint(job,. "Arrived DLI:. " + Bucket) 
print obs." ) 


//LINEG 
Bucket = dw _2.getitemstring(1, "race") 
if isNull (Bucket) then; Bucket = blink; end if 
erint(job; tiy "Race: + Bucket, C2) 


Bucket = dw _2.getitemstring(1, “ult_mos") 
if isNull (Bucket) then; Bucket = blnk; end if 


prank (j7ob, “UMOS: 7 + Buecker,” C2br) 
Bucket = string(date(dw_2.getitemDateTime(1, "d_unit"))) 
if isNull (Bucket) then; Bucket = blnk; end if 
print(job) “Arrived Unit: “+. Bucket.) 
Pranic joo, i") 
//LINE7 


Bucket = dw_2.getitemstring(1l, "mealcard”) 

if isNull (Bucket) then; Bucket = blnk; end if 
print(job, tl, “Mealcard: " + Bucket, t2 ) 

Bucket = dw_2.getitemstring(l, "sm_status") 

if 1SNull (Bucket) then; Bucket = bink; end if 

print(j ob, “SM Status: "+ Bucket, t3b..) 

Bucket = string (date (dw_2.getitemdateTime (1, "ets"))) 
if isNull (Bucket) then; Bucket = blnk; end if 
Orini(job,y, “ErtsS=. * + Bucker: -) 

prantc(jo6b;; "> 


/ /LINES 
Bucket = dw 2.getitemstring(1, "qs1") 
if isNull (Bucket) then; Bucket = blink; end if 
print(job, t2, "QS1: " + Bucket) 
Princ( job," «) 
print(job, dashes} 
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print (job, "") 


vt ey 


Prine (job, 


//DEPN PART OF FORM 


Bucket = dw 3.getitemstring(1,.“depn nm spouse”) 


if isNuli(Bucket) then; Bucket = ""; end if 
print(job, tl, "Spouse's Name: " + Bucket, t3b ) 
Bucket = dw_3.getitemString(i, "depn numb chil”) 
if isNull (Bucket) then; Bucket = ""; end if 
print(job, "Number of Dependents: " + Bucket) 
Print(jeb, “™) 

print (job, dashes) 

Prane (job, 1") 

Pranttj}ob; -"™) 


//LOCATION PART OF THE FORM 


Bucket = dw_4.getitemstring(1, "loc addr") 


if isNull (Bucket) then; Bucket = ""; end if 
print (job; tl, "Address: " + Bucket, t3) 
Bucket = dw_4.getitemString(1, "loc qgtrs") 
if isNull (Bucket) then; Bucket = ""; end if 
print( ob, “Quarters: " + Bucket) 
prant(job, 

Bucket = dw_4.getitemString(1, "loc city") 
if isNull (Bucket) then; Bucket = ""; end if 
Print{ ob, ‘tl, "City: " + Bucket, ‘t2-) 
Bucket = dw_4.getitemString(1l, "loc state") 
1f isNull (Bucket) then; Bucket = ""; end if 
print(job, "State: " + Bucket, t3 ) 

Bucket = dw_4.getitemString(1, "loc zip") 
if isNull (Bucket) then; Bucket = ""; end if 
print(job, "ZIP: " + Bucket ) 

Prink(job.: *") 

Bucket = dw_4.getitemString(1l, “loc phone") 
if 1sNuli(Bucket) then; Bucket = ""; end if 
princi job; ti;: “Phone:.-” + Bucket, t2 ») 


P/OrInetjoD; -") 
Bucket = dw_4.getitemString(1l, "consent"™) 


if isNull (Bucket) then; Bucket = ""; end if 
print (job, "Consent: ™ + Bucket) 
Praneryop,. ") 


printclose (job) 


else 


messageBox ("PRINT REPORT", "No printout available for this form.") 


end if 


return 
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{//EXTENDS ANCESTOR SCRIPT 


saveData () 

string newName, newSSN, testSSN //containers for personal data 
string dwFilter //dataWindow filter string 
string bldg, rm, bunk //dormitory assignment 

string Bucket //temp 

int msgCode //return value of messageBox 

Ei oye dwCnt //dataWindow count 

baghe checkCnt //counts successful dataWindow updates 

int ig see //counters 

long currRow //current row indicator 


dwCnt = upperBound(dwList[]) 


window otherSheet 
userObject uox 
dataWindow dwxX 
dwitemStatus rowStat 


setPointer( hourGlass!) 


for 1 = 1 to dwCnt 
dwList fi] .acceptText () 
next 


if (dw_l.dataObject = "d_regadmini") AND (dw_1.modifiedCount()) > 0 
then 


newSSN = dw_l.getItemString( 1, "ssnadmin") 
testSSN = dw_l.getItemString( 1, "ssnadmin", PRIMARY!, TRUE) 


if newSSN <> testSSN then 
Bucket = "mil.changeviewssn '" + testSSN + "', '"& 
+ newSSN + "'" 


EXECUTE IMMEDIATE :Bucket; 


if sqica.sqicode < 0 then 
xX = messageBox("Data Entry Error", & 
"Change of SSN failed.~n"é& 
+ sqica.SQLErrText + "~-n~n"& 
+ "Restore original SSM?", question!, 
YesNoCancel!, 1) 
choose case XxX 
case l 
dw _1.setFocus () 
dw _1.setColumn( "ssnadmin") 
dw_1.setText( testSsN) 
dw I.acceptText () 


ease 2 
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case else 


end choose 


dw J .setitcemsStatus(. ., 


//update SSN in other dws 
dw 2.getItemStatus ( 
if (dw_2.modifiedCount()}) > 0 then 
w_admin.dw_2.setitem(1, 
dw zZ.setItemStatus( 1, "“ssntarget", Primary!, & 
NotModified!) 


w_admin.dw_2.setItem(1, 





//do nothing 


"ssnadmin", NotModified!) 


"ssntarget", 


"ssntarget", 
NotModified! ) 


setItemStatus ( 


w_admin.dw_3.setItem(1i, 


dw _2.getItemStatus( 1, 


dw: -5.getivemstatus( Jy 

1f (dw_3.modifiedCount()) > O then 
w_admin.dw_3.setItem(1, 
dw_3.setItemStatus( 1, "ssntarget", Primary!,& 

NotModified! ) 


"ssntarget", 


"ssntarget", 
Primary!, NotModified! ) 


setItemStatus ( 


— 


w_admin.dw_4.setItem(1, 
dw _4.setItemStatus( 1, 


//reset vo 1 in this and other sheets 
Pease Dest ooaN.. + 
uc: Jwdw toco..taind( Bucket, 
uc_1.dw_loco 


otherSheet 


otherSheet = 


do while isValid(otherSheet) 
1 to upperBound( otherSheet.control{] 


dw_3.getiItemStatus( l, 


dw _4.getItemStatus ( 

if (dw _4.modifiedCount()) > 0 then 
w_admin.dw_4.setItem(1, 
dw 4.setItemStatus( 1, 


"ssntarget", 
"ssntarget", 
NotModified!) 


Primary!, & 


"ssntarget", 
Primary!, NotModified!) 


dw 4.getitemStatus( |, 


il 


w frame.getFirstSheet () 
w_ frame.getNextSheet (otherSheet) 


if otherSheet.control[i].className() = "uo_1" then 
//assign to userObject variable, 
//so that control[}] can be used 
uoX = otherSheet.control [i] 


for xx = 1 to upperBound( uoX.control[] ) 


if uoX.control[xx].className() = "dw_loco" then 
//assign to dataWindow object, : 
//so that reset() can be used 
dwX = uox.control [xx] 
dwX.reset () 
xx = 100 //sentinel used to exit loop 
i= 100 //sentinel used to exit loop 
end if 
next 
end if 
next 


otherSheet = w_frame.getNextSheet (otherSheet) 


loop 
end if 
end if 
if (dw_2.modifiedCount()) > QO then 


CHOOSE CASE dw_2.dataobject 


CASE "d_ admin" 
w _admin.dw_2.setitem(1, "tdate", today()) 
w_admin.dw_2.setitem(1, "uname", sgqica.userid) 


CASE "d_adminnew" 


dw _2.setColumn("n_student") 
newName = trim(dw_2.getText ()) 


if newName = "" then. 
messageBox ("Data Entry Error", & 
"New record cannot be created without a name.", & 


stopSign! ) 
dw 2.setFocus () 
return 
end if 


//check if attempt to create new record 
//without unit at Company level 
dw 2.setColumn (“unit”) 


Lf (trim(dw 2.<getText()) = mt) AND (company <> "") then 
messageBox("Data Entry Error", & 
"New record cannot be created without a Unit.",& 
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CAS 


CAS 


END 
end if 





stopSign!) 
dw_2.setFocus() 
return 
end if 


dw Z-acceptlrext()) 
dw 2.setColumn ("ssntarget") 
newSSN = trim(dw 2.getText()) 


if newSSN = ""— then 
messageBox ("Data Entry Error", & 
"New record cannot be created without SSN." 
stopsSign!) 
dw 2.setFocus () 
return 
end if 


if newSSN <> fetch ssn then 
fetch ssn = ue 
end if 


if w_admin.dw_1.modifiedCount() > 0 then 
w_admin.dw_l.setItem(1, “ssntarget", newSSN) 

end if 

1£ w_admin.dw_3.modifiedCount() > 0 then | 
w_admin.dw_3.setItem(1, "ssntarget", newSSN) 

end if 

if w_admin.dw_ 4.modifiedCount() > 0 then 
w_admin.dw_ 4.setItem(1, “ssntarget", newSSN) 

Bric: 5 

fetch ssn = newSsSN 

w_admin.dw_2.setitem(1, "tdate", today()) 

w_admin.dw_2.setitem(1l, "uname", sqlca.userid) 

BE 'd.tormgo” 

af dw o.rowCount() > 0: then 


for currRow = 1 to dw_6.rowCount () 


rowStat = dw_6.getItemStatus( currRow, Q, 
if (rowStat = newmodified!) 
or (rowStat = datamodified!) then 
dw 6.setitem{ currRow, “d.tran”,. today()) 
dw 6.setitem(. currkow, "n. user”, sqlcacuserid) 
end if 
next 
dw _6.update() 
end if 
E ELSE 


//do nothing 


CHOOSE 
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PRIMARY ! ) 


& 


if (dw_3.modifiedCount()) > 0 then 
w_admin.dw_3.setitem(1, "tdate", today() ) 
w_admin.dw 3.setitem(1, "uname", sqlca.userid) 
end if 


if ( dw _2.dataObject = "d_admin") AND ((dw_4.modifiedCount() > 0) OR 
(dw _5.modifiedCount() > 0)) then 
Bucket = dw_4.getiItemString( 1, “loc_qtrs”") 
if ( Bucket = "B") OR ( Bucket = "BRKS") then 
if dw 5. modifiedCount{) > 0 then 
bldg = dw_5.getItemString( 1, "bldg") 
rm = dw_5.getItemString( 1, "rm") 
bunk = dw_5.getItemString( 1, "bunk") 


iT fecckh- sso a” Len 
fetch ssn = dw_2.getItemString( 1, "ssnTarget") 
end if 


if isNull({ bldg) OR isNull( rm) then 
messageBox ("BARRACK DATA SAVE", "You need to provide "& 
+ "at least Bldg and Room when "& 
+ "specifying location.") 


return 

end if 

if trim( bunk) = "" then 
setNull( bunk) 

end if 


msgCode = 0 


Gwralter =" 
Gw 6. 56trildter( dwrilter) 
dw 6.fiiter() 


if dw_6.rowCount() = 0 then 
dw 6.retrieve( company) 
end if 


//check out from existing accomodation, if any 
Bucket = "brks act _ssn=~"" + fetch_ssn + "~"™ ®™ 
currRow = dw_6.find( Bucket, 1, dw_6.rowCount () ) 
if: currRow > 0 ther 

setNull( Bucket) 

dw 6.setItem( currRow, "brks_act_ssn", Bucket) 


end if 


//check if bldg and room exists 
dwFilter = "brks act bldg=~"" + bldg + "~" "& 


+ "and DEks acto 1m=="" +> > “eo Soe 
dw _6.setFilter( dwFilter) 
dW: Ov rLbter () 
Bucket = "" 
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if dw_6.rowCount() = 0 then 
Bucket = "No such building and room is assigned "& 


else 


+ "to your Company.~n~n"& 

+ "Do you want to drop your Building and "& 
+ "Room assignment "& 

+ "and save the rest of the data?" 


Bucket = "brks_act_bunk='" + bunk + "'" 
currRow = dw_6.find( Bucket, 1, 10) 


1£ currRow = 0 then 


Bucket = "No such bunk in Room "+ rm + ".-n"& 
+ "You can open Barracks Utilization window "é 
+ "and add another bunk for this room. "& 
+ "Then try the 'Save' operation again.~n~n"é 
+ "Do you want to drop your Building and "& 
+ "Room assignment "& 
+ "and save the rest of the data?" 
else 
Bucket = "" 
end if 
end if 
1f Bucket <> "" then 


msgCode = messageBox( "BARRACK DATA SAVE", & 


Bucket, question!, yesNo!, 1) 


-1f msgCode = 2 then 


return 


end if 


end if 


if msgCode = 0 then 
//check if bunk is available 
if isNull( bunk) then 


//find ist available bunk in the room 


Bucket = "isNull( brks_ act ssn)" 
else 
//check if given bunk in given room is empty 
Bucket = "isNull( brks act_ssn) "& 
+ Nand brks .act Sunk="'" -- bunk: ai Wee 
end if 


currkow = dw 6:tind( Bucker,;. 1;. 10)... 


if currRow = 0 then 


Bucket = "Room is already fully occupied. ~n~n" & 
+ "Do you want to replace current occupant?" 
msgCode = messageBox( "BARRACK DATA SAVE", & 
Bucket, question!, yesNo!, 2) 


if msgCode = 1 then 
if isNull( bunk) then 
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-currRow = 1 //assign arbitrarily bunk A 
bunk = "A" 

else 
Bucket = “brks_act_bunk='" + bunk + 
currRow = dw_6.find( Bucket, Il, 10) 


end if 

else 
return 

end if 

else 
- if isNull( bunk) then 
//assign first available bunk in room 
bunk = dw_6.getItemString( currkRow, & 
"pbrks_ act _bunk") 


= "not isNull( brks_act_ssn)" 
i = max( 1, dw_6.find( Bucket, LO) 
= dw_6.getItemString( i, "admin_sex") 


if ( not isNull( Bucket)) & 
AND ( Bucket <> dw_2.getItemString( 1, "sex")) then 
messageBox( "BARRACK DATA SAVE", & 
"Sex mismatch.~n~n"& 
+ "Open Barracks Utilization window "& 
+ "and resolve the discrepancy. "& 
+ "Then try the 'Save' "é& 
+ “operation again."™) 
return 
end. 1f 


dw 6.setItem( currRow, "brks_act_ssn", fetch_ssn) 
dw 5.setItem( 17. “punk” ,. bunk) 


setNull( Bucket) 
dw 2.setItem( 1, "mealcard", fetch_ssn) 


ene 55 
end if 
else 
//not living in barracks anymore => checkout 
dwFilter = "" 
aw. 6.SeT River | dwFilter) 
Ow: 6.21 LCer (y. 
if dw_6.rowCount() = 0 then. 
dw_6.retrieve( company) 
end if 
Bucket = "brks_ act_ssn=~"" + fetch ssn + "~" " 


currRow = dw_6.find( Bucket, 1, dw_6.rowCount()) 


if currRow > O then 
setNull( Bucket) 
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dw_6.setItem( currRow, "brks_ act ssn", Bucket) 


ena if 
end if 
if (dw_4.modifiedCount()) > 0 then 


dw_4.setItem( 1, "uname", sqlca.userID) 
ow 4.setitem(. 1. “tdate”,. today ()) 
end 2 
end LF 


dw_5.resetUpdate () 
checkCnt = 0 


for 2 .=-1 te dwent 
//if i <> 2 then //exclude dw 5 
if dwList[i].className() <> "dw_5" then 
checkCnt += dwList{i].update() 
else 
checkCnt += 1 
end if 
next 


if (checkCnt = dwCnt) then 
COMMIT using sqlica; 


if dw_2.dataobject = "d_adminnew" then 
uo_j.dw_plt.retrieve (company) 
uo_1i.dw_loco.retrieve (company) 
uo. 1. aw loco.Filter() 

end. 25 


if newSSN <> fetch_ssn then 
fetch ssn = newSSN 
//triggerevent( cb fetch, clicked!) 
fetchData () 
primeNewRows( fetch_ssn) 
end. a7 


else 
messageBox ("Data Entry Error", "Database update operation failed.", 


stopSign!) 
ROLLBACK using sqlca; 
end if 
if dw_6.visible=true then 
dw _6.bringToTop=true 
end if | 


return 
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//PARAMETERS : 
//RETURN: 
//PURPOSE: 

i 7 

ee 


int 


readonly string newSsSN 
O - success 
Inserts new row in selected dataWindows, 
set the value of SSN to passed parameter, 
set the row status to NEW! 


int primeNweRows ( readonly string newSSN) 


if this. .rowcount () 
this. 
this: 
this. 
this. 


end. 12 


.setitem(l, 


.rowcount () 
.insertrow ( 
.setitem(i, 


Er -tnis< 
this 
tha Si 


_insertrow(0 


.setitemStatus (1, 
.setiItemStatus (1, 


) | 
"ssntarget", newssn) 
"ssntarget", 


"Ssntarget", PRIMARY! 


= 0 then 


"ssntarget", newssn) 
PRIMARY! 


PRIMARY ! 


dataModified!) 
notModified!) 


dataModi fied! ) 


"ssntarget”, 
"ssntarget", 


~.setitemStatus (1, 
~setitemStatus (1, 


Chas’ 
this. 
end if 


PRIMARY!, notModified!) 


-rowcount() = 0 then 
.insertrow(0 

-setitem(1;. “Ssnhterger”, 
.setiItemStatus(1, "ssntarget"”, 


_setiItemStatus(l, "ssntarget", 


if this. 
this: 
this. 
Chis 
thas. 

end if 


newSsn) 
PRIMARY ! 
PRIMARY!, 


dataModified!) 
notModified!) 


~ 


return 0 





//PARAMETERS: readonly string formType 

//RETURN: int 0 - success 

// PURPOSE: Assigns dataWindow objects to dataWindow controls 
ce depending on the formType 


int setw_admin ( string formType) 


//form type | 
//list of table permissions 
//cemp 

//counters 


string selectedForm 
string permList 
string Bucket 

int xx, dwCnt 


triggerEvent (closeQuery'! ) 


if ( this.title <> formtype) OR ( formtype = " Inprocessing ") then 
this.title = formtype 
selectedForm = upper(left(formtype, 4)) 
if {zetCch-ssn = "iy AND (selectedForm <> "PT 1") then 


messageBox ("NEXT SOLDIER", & 
"Porm Pt 2 and Pt 3 are not for new soldiers. 


+ "Do you wish to create a new record?”,& 


c= 
~n" & 


132 








Information!,& YesNo!, 1) 


if xx = 2 then 
return ‘—i 
end if 
end if 


this.setRedraw( false) 


dwCnt = upperBound( this.dwList) 


1f dwCnt = 0 then 


dwCnt = getDwLlist( this, dwlist) 
end <i 
this.dw_1l.datacbject = "d_ regadmin1” 
choose case selectedForm 
case: "PT..ie 
this.dw_2.dataobject = "d_ admin" 
this.dw_3.dataobject = "d depn" 
this.dw_ 4.dataobject = "d local" 
this.dw 5.dataobject = “d brk loc” 
this.dw_6.dataobject = "d bunk" 
case: VEL. 2" 
this.dw 2.dataobject = “"d form90" 
this.dw_3.dataobject = "d trgdata" 
this.dw_ 4.dataobject = "d office" 
this.dw S.reset() 
this.dw_6.dataObject = "d dipt hist" 


case "PT 3" 
this.dw_2.dataobject 
this.dw_3.dataobject 
this.dw_4.dataobject 
this.dw._o.reset() 
this.dw 6 reset) 


case else 


"d_ reserve" 
" d_comp " 
A ds ec vr 


//messageBox ("INPROCESSING", "Need to specify form.") 


Chas.uo adminmenu.st 1nprocessing.triggerEvent("lbuttonup”) 


this.setRedraw(true} 
return 1 


end choose 


for xx = 1 to dwCnt 
dwList [xx] .hide() 
[ 


dwList [xx] .setTransOb ject (sqica) 


next 


//fenable/disable SAVE menu based on permissions 


setSaveMenu () 
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//find if user can create record for new soldier 
permList = space (4) 
sqlca.getSUID( "admin", sqlca.userID, permList) 


Le POS permuist, *1") 2 O-then 
this.cb add.show() 


Lf fetch.ssn =" then 
triggerEvent (this.cb add, clicked!) 
this.setRedraw (true) 
return 0 
end if 
end if 
this.setRedraw( true) 
Bucket = "Enter/Edit Necessary Information and "& 
+ "Select SAVE or Continue to "& 
+ "Select Additional Information." 


w frame.setMicroHelp( Bucket) 
end if 


return 0 


8. Using Pipelines for Data Synchronization 

PowerBuilder provides a feature, called data pipeline, which makes it possible to 
copy records from one or more source tables to a destination table. The destination table 
may already exists, or can be automatically created in the destination database at the 
time of data transfer. Data source and data destination can reside in the same database, 
or be in two separate databases managed by different DBMSs. Data pipes are applied in 
MILDB application for synchronization of data between remote local databases and the 


central database. There are five basic steps in data pipeline setup and execution: 


° Step 1: Building supporting objects. 
@ Step 2: Connections setup. 
® Step 3: Starting the pipeline and monitoring progress. 
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Step 4: Handling row errors. 


Step 5: Closing pipeline. 


a. Building Supporting Objects 


To implement a data pipeline, three objects are needed: Pipeline object, 


user object hosting the pipeline object, and a window for pipeline logistics. 


(1) Pipeline Object 


Pipeline object is created by means of PowerBuilder’s object 


wizard. Pipeline object specifies: 


Source of data (one or more tables or views). 

Data destination (destination table or view). 

Type of piping operation (i.e., create new destination table and populate it 
with piped data; or: replace the contents of existing destination table with 
piped data; or: update data in destination table selhig piped data; or: append 
the destination table). 

Frequency of commits (indicates how often, after how many piped rows, 
should a COMMIT SQL statement be issued). 

Allowable number of errors (indicates number of errors that will be 
tolerated before the execution of data piping will be suspended. Error 
messages, along with the data, are captured in a dataWindow for further 
processing). 

Piping of extended attributes (indicates, whether extended attributes of 


the source data items are to be also piped to destination database). 
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Figure 17 shows an example of a pipeline object for piping data from central to 


local MILDB database. 


“';; Data Pipeline - milstu_to_admin 
|| Table: fadmin ae Key: 
{| Options: {Update - Undater|nsert Rows Max Errors: ” 


Commit: fi a 


: sates Name ore pe [Destination Name {Typ =o. J e y Width Dec Null “nitial Value | 


achat ‘pay, ipa gd d “VARCHAR a 3 : 
12, I ec5lc ho me ie ee 
‘varchat{9} ipmos : ) 
}smaliint ‘dab 3 IT 
a eae ~ WARE a ee 
:yarchar{1} “Hace “VAR CHAR qc 

i ee soe ere aaa ee 


eee ta, Shia 


week famed 


Vvarcharti). RRA 
pare sqd-SS”*~S*~*~*CWARCHAR 


pol 


| 
| 
| 
| 
| 
| 
| 
| 


datetime 
achat 





placeofbirth 


Alt 





Figure 17. Pipeline Object milstu_to_admin 


(2) Supporting User Object 

Pipeline object is similar to dataWindow object. It contains 
selection of columns from both the source and destination tables, but the object has no 
properties, events, or functions. To acquire these, the pipeline object needs a host 
object. PowerBuilder provides for this purpose a special pipeline system object, which 


contains properties, events, and functions needed for pipeline operations. 
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Pipeline properties include: 


® Data Object (name of pipeline object). 

° RowsRead (cumulative number of rows read since the pipeline started). 
° RowsWritten (cumulative number of rows written to destination table). 

° RowslInError (number of rows rejected by the destination database). 


Pipeline events include: 
° PipeStart (triggered when pipeline starts). 
® PipeMeter (triggered after every COMMIT command). 


° PipeEnd (triggered when pipeline finishes execution, or is stopped). 


Pipeline functions include: 

° Start (starts the pipeline). 

ee | Repair (attempts to write corrected, previously rejected, rows to 
the destination database). 


e Cancel (cancels pipeline execution). 


The following code shows scripts from non-visual object o_synchro_pipe: 
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//USER OBJECT O SYNCHRO PIPE 


//INSTANCE VARIABLES 
staticText statusRead, statusWritten, statusError //for pipe status 


data 

staticText flowAnimation //for pipe flow animation 

string arrowText //tcext of flowAnimation 

boolean toLeft //indicator of direction of animation 
char arrowChar l7 Char '<* or “S" for anim 


//EVENT PIPESTART 
arrowtext = flowAnimation.text 


//set the char to be added to arrowtext to achieve animation effect 
if pos( arrowtext, "<") > 0 then 
toLeft = true 


arrowChar = "<" 
else 

toLeft = false 

arrowChar = ">" 
end if 


//EVENT PIPEMETER 
statusRead.text = string( rowsRead) 


statusWritten.text = string( rowsWritten) 

statusError.text = "Rows in error~r" + string( rowsInError) 

long posOut //position of char to be removed from arrowText 
char chariIn //adds char to pipe movement animation 


if rowsInError = 100 then | 
messageBox( "DATA PIPE", "100 rows have one or more data items "& 


+ "that were rejected "& 
+ "by destination database. ~n~n"é& 
+ "Click 'Apply Known Fixes' and ‘Continue’, "& 
+ "or correct the errors "& 
+ "manually and click 'Continue'.") 
end if 


//to create animation effect of moving errows: 
//at given interval of rowsWritten add space or ">" at one end of 


string 
//and remove one char at the other end 
if rowsRead = rowsWritten then 
if mod( rowsWritten, 4) = 0 then 
charIn = arrowChar 
else 
cherin =" ” 
enc. af 
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if toLeft = true then 


arrowText = arrowText + charin 
posOut = 1 
else 
arrowText = chariIn + arrowText 
posOut = len( arrowText) 
end if 
arrowText = replace( arrowText, posOut, 1, "") 
end if 
flowAnimation.text = arrowText 
(3) Window 


Window that will provide logistics for a pipeline needs to contain 
the following objects: 

_e PDataWindow contro! (pipeline will insert into this dataWindow any row in 
error. Later, these rows can be corrected and an attempt can be made to 
write them to the destination database by calling a function repair() ). 

e Optional command buttons for pipeline start, repair, or cancel. 

e Optional text field for displaying the number of rows read, written, and rows 
in error. - 

e Other optional controls, informing the user about the pipeline progress, such 


as direction of data flow, etc. 


The pipeline window in MILDB application provides numerous features that allow 
a successful execution data synchronization even by an occasional user, such as: 
e Visual selection of data source and destination. 


° Visual selection of source tables to be synchronized. 
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7 Animated indicator of data flow. 

e Pipeline start/stop button. 

e Display of the number of rows read, written, and in error. 

6 | Button for applying fixes of the most common data errors. 

° Button for resuming the pipeline operation after applying the fixes. 


e Button for suspension of pipeline operation. 


Figure 18 shows the design of a window supporting pipeline operation. 





“+ COMPANY A DATABASE | Far} 
ae Folder _Windaw Pe MBI Fe tae aE ag Oe eh a eee ee 


mI > > >> 6 > or Ceritral | °F APFT a FORM 90. TO REPR- 
° oo i a © MILDB T ARTIS © ISSR T-TRAINING 
Rows Read Stat | Rowswrten AWOL COCATION NT WEIGHT 
| | — 8 BAR. RELPTH | T WPNTRN 
ies | (F CSTICST FF TRNPLAN i 
_ 1 CHAPTER IT” MAN TRN 
ae [DEPEND [ OFFICE 
--T.OLPT |. 7 PREGNANCY: 


| Apply Known Fixes | | ‘Continue | _& nore | T FAMCARET PERMPARTY —— 











Figure 18. Window w_pipe 
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b. Connections Setup 


In order to prepare the window for pipeline execution, the following tasks 


need to be accomplished: 





Establish connection with the source and destination database: 


//transaction object for source DATABASSE 
transaction sourceConnection 


sourceConnection = CREATE transaction 


//transaction object for destination database 
transaction destinationConnection 


destinationConnection = CREATE transaction 


//ODBC connection setup 
sourceConnectString = "ConnectString='DSN=MILX'; 


destConnectString = "ConnectString='DSN=milstu' 


//connect to databases 
CONNECT using sourceConnection; 


CONNECT using destinationConnection; 


Instantiate the host user object: 


//pipe user object 
Oo synchro pipe pipeLogistics 


pipeLogistics = CREATE o synchro pipe 
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° Assign the pipeline object: 


pipeLogistics.dataObject = <pipeObjectName> 


c. Starting Pipeline and Monitoring Progress 
The basic syntax for starting the pipeline execution is: 
<[int] return code> = <pipeline userObject> . Start(<source Trans. Object>, & 
| <destination Trans. Object> , & 


<name of dataWindow for storing errors>) 


The return code indicates successful start of pipeline, or possible causes of 
failure. The following code shows scripts for database connections, setup of the pipeline, 


and starting the pipeline, contained in window w_pipe: 


//***WINDOW W_PIPE 


//INSTANCE VARIABLES 
transaction sourceConnection //transaction.obj)ect 
//for source DATABASE 


transaction destinationConnection //transaction object 
//for destination database 


o synchro pipe pipeLogistics //pipe user object 
checkBox taskBoxList[] //array of controlBoxes 
boolean hideHelp //hnide help true/false 
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//WINDOW EVENTS 
//WINDOW OPEN EVENT | 


//Local variables 
int. 2e% -yVy //step counters 


disconnect; 


sourceConnection = CREATE transaction 
destinationConnection = CREATE transaction 


//instantiate pipe object for pipe logistics 
pipeLogistics = CREATE o_ synchro pipe 


//link window status text objects with text object of pipeLogistics 
pipeLogistics.statusRead = st_rowsread 

pipeLogistics.statusWritten = st _rowswritten 
pipeLogistics.statusError = st_rowsinerror 
pipeLogistics.flowAnimation = st_pipeFlow 


//initialize list of checkBoxes 


vy Sd 
for xx = 1 to upperBound(this.control[]) 
if this.control[xx].typeOf() = checkBox! then 
taskBoxListfyy] = this.control [xx] 
yytt 
end if 
next 


//EVENT MOUSEMOVE 

if hideHelp = true then 
St. Start. hade() 
st_fix.hide() 
st. continue .hide() 
st. ignore: hide () 
hideHelp = false 

end if 


//WINDOW FUNCTIONS 

//PARAMETERS: string boxTxt - text label of checkBox control 
//RETURN: boolean true/false 

//PURPOSE: Indicates whether checkBox is checked 
isChecked( string boxTxt) 


int xx //counter 


for xx = 1 to upperBound( taskBoxList{]})} 
1f lower( taskBoxList[xx].text) = lower( boxTxt) then 
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if taskBoxList[xx].checked = true then 
return TRUE 
else 
xx = 1000 
end if 
end if 


next 


return FALSE 


//EVENTS OF CONTROLS 


//BUTTON cb start 
//CLICKED EVENT 


string sourceDsn, destDsn //data source names 


string sourceConnectString, destConnectString //connection strings 
string pipeObjectName //name of pipe object 
string pipeList[] //array of pipes 
Strang :Bucker . | //temp 

int xx : } //step counter 

int startFlag | //pipe start flag 


long currRow, maxRow 
long posx 


pipeList = { "admin", "“apft","artl5", Vawol", “barry "ce. trne", & 


"chap", "“deopn", “dipt", “fceare™, "flag’, “Lormgo”;%& 
wiese’, “ioe, “ipch’;. “ine plan, "Mm -trng", “Office” pk 
"preg", "orm prty", VOLO 5 io al — 1 OS TENG 4 Mier; & 
"won i } 

if this.text = "Start”™ then 


if rb milx.checked = true then 


//data transfer from MILX to MILSTU 


sourceDsn = "MILX" 
GestDsn = "MILSTU" 
sourceConnectString = "ConnectString='DSN=MILX'; "& 
+ PSE ” 'ttthhemm:ss:'''! ae aa 
+ "delimitidentifier='NO';"& 
+ " MsgTerse='Yes!" 
destConnectString = "ConnectString='DSN=milstu';"& 
+ " MsgTerse='Yes'" 
else 


//data transfer from MILSTU to MILX 
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sourceDsn = "MILSTU" 
destDsn = "MILX" 


sourceConnectString = "ConnectString='DSN=milstu';"& 
+ " MsgqTerse='Yes'" 


destConnectString = "ConnectString='DSN=MILX'; "& 
: + "Pime=" '''*hhatmm: ss: ' 71? "ss 
+ "delimitidentifier='NO';"& 
+ " MsgTerse='Yes'" 
end af 


//set properties of transaction objects 
sourceConnection.dbms = "ODBC" 
destinationConnection.dbms = "ODBC" 


sourceConnection.dbParm = sourceConnectString 
destinationConnection.dbParm = destConnectString 


//// Profile milstu_native 

//SQLCA.DBMS = "MSS MS Microsoft SQL Server 6.x" 
//SQLCA.Database = "mildb" 

//SQLCA.LogPass = "mil" 

//SQOLCA.ServerName = "pomdb" 

//SQLCA.LogiId = "mil" 

//SQLCA.AutoCommit = False 

//SQLCA.DBParm = "" 


//connect to source and destination databases 
disconnect; 
CONNECT USING sourceConnection; 


if sourceConnection.sqlcode < Q then 
messageBox ("DATABASE CONNECT", "Could not connect to "& 
+ sourceDsn + ".", exclamation!) 


return 
end if 


CONNECT USING destinationConnection; 


if destinationConnection.sglcode < 0 then 
messageBox ("DATABASE CONNECT", "Could not connect to "& 


+ destDsn + ".", exclamation!) 
DISCONNECT USING sourceConnection; 
return 
end if 
this.text = "Stop" 


//set pipe object 

for xx = 1 to upperBound( pipeList[]) 
//check if table to pipe selected 
if isChecked( pipeList{xx]) = true then 
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//get pipe object name 
if rd: milx-checked = true then 


if pipeList{xx] = "dipt" then 
continue 
else 
pipeObjectName = "milx to_" + pipeList[xx] 
end if 
else 
pipeObjectName = "milstu_to_" + pipeList [xx] 
end if 


pipeLogistics.dataObject = pipeObjectName 
//***start pipe 
startFlag = pipeLogistics.Start( sourceConnection, & 


destinationConnection, dw_pipe errors, Company) 


Bucket = "™" 


choose case startFlag 


case -l 
Bucket = "Pipe open failed." 
case -5 
Bucket = "Missing connection." 
case -15 
Bucket = "Pipe already in progres." 
case -16 : 
Bucket = "Error in source database." 
case -l/7 
Bucket = "Brror in destination database." 


end choose 


if Bucket <> "" then 
messageBox( "PIPE ERROR", Bucketé 
+ "xn~nOperation halted.", exclamation! ) 
return 
end if 
end if 


maxRow = dw pipe errors.rowCount () 


if maxRow > O then 
for currRow = 1 to maxRow 
Bucket = dw_ pipe errors.getItemString( currRow, 1) 


posX = pos( Bucket, ":") 


if posX > 0 then 
Bucket = mid( Bucket, posx + 1 ) 
dw pipe errors.setitem( currkRow, 1; Bucket) 


end if 
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DISCONNECT USING sourceConnection; 
DISCONNECT USING destinationConnection; 





this.text = "Start" 
else 
//call the Cancel function of pipe object 
if pipeLogistics.Cancel() = 1 then 
Beep (1) 
this.text = "Start" 
else 
messageBox( "PIPE ERROR", "Error while trying to stop data 
transfer.", exclamation!) 
end if 
end if 
//EVENT MOUSEMOVE 
it this.,text.= “Start” then 
St start, text = “Start piping data from selected: tables” 
else 
St. Startl.text. = "Stop: piping: data” 
end if 
st_start.show() 
hideHelp = true 
//RADIO BUTTON rb_milx 
//EVENT CLICKED 
st milx.text = "FROM~rLocal" 
St. maistu,text. = “TOrvrCentral” 
st_pipeFlow.rightToLeft = false 
Si piper tow. text =" > > > > > > 
st_milxrows.text = "Rows Read" 
st_milstuRows.text = "Rows Written" 


trtt 


st _rowsread.text = 
St..rowswritten. text = 
St. POWSINELT OL. text = 
st _rowsread.X = st_milxrows.xX 

st_rowswritten.X = st_milstuRows.X 


TF tr 


vt tt 


dW Di pe.errors reset () 


//RADIO BUTTON rb STU 
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>t 


//EVENT CLICKED 

st mMilx. bext = "TO-rboecaL” 

St milstu.texc = “FROM=r1CentraL™ 

st: ‘piper low<rightToLere = crue 

st pipeFlow.text = "< < < < < < < < <« < 
st_milxrows.text = "Rows Written” 

st_milstuRows.text = "Rows Read" 

st_rowsread.text = "™" 
st_rowswritten.text = 
st_rowsinerror.text. = 
st_rowsread.X = st_milstuRows.X 
st rowswritten.X = st_milxrows.X 


or or 


te TF 


dw pipe errors.reset () 


//BUTTON cb continue 
//CLICKED EVENT 
if pipeLogistics.repair( destinationConnection) <> 1 then 
messageBox( "PIPE ERROR", "Error when trying to apply"é 
+ “" fixes.~n~n"& 
+ "Check you data or choose to ignore rows "& 
+ with errors.”", & 
exclamation! ) 
end if 


//EVENT MOUSEMOVE 
st _continue.show() 
hideHelp = true 


//BUTTON cb_ignore 
//CLICKED EVENT 
dw pipe errors.reset () 


if pipeLogistics.repair( destinationConnection) <> 1 then 
messageBox( "PIPE ERROR", "Error when trying to apply fixes.",& 
exclamation!) 
end if 


//EVENT MOUSEMOVE 
st_ignore.show() 
hideHelp = true 


148 











d. Handling Row Errors 


When a pipeline is unable to write particular rows to the destination table 
due to some errors (i.e., violation of the primary key, violation of referential integrity, 
etc.), these rows are inserted into the pipeline error dataWindow. When the number of 
rows in error reaches the maximum indicated in the pipeline object, execution of data | 
piping is suspended. The user has an option to discard rows in error and resume the 
pipeline operation, or correct the data and attempt to write them to the destination 
database by calling the function: | 


Repair( <destination trans. object> ) 


Before the pipeline can resume its normal operation, repaired rows that were 
written to the destination database have to be committed by statement 


COMMIT using <destination trans. object> ; 


e. Closing Pipeline 

When the data transfer is concluded, there is no need to explicitly destroy 
objects that were dynamically created in preparation for pipeline execution. 
PowerBuilder’s garbage collection mechanism will remove these objects automatically 
after they seize to be referenced in scripts. Good programming practice still calls for 
disconnecting the application from both the source and destination database, using 
commands: 

DISCONNECT using <source trans. object> ; — 


DISCONNECT using <destination trans. object> ; 
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9. Running the MILDB Application 

When a _— starts the MILDB application, he/she is challenged by the database 
authentication procedure. After passing the authentication test, a window frame with the 
main menu bar opens. The user can choose from three major areas of operation listed in 
the Folder menu: 

e Administrative (represented by a ‘pencil’ icon on the menu bar). 

e Physical Training & Weight Control (represented by a ‘running man’ icon on 

the menu bar). 
e Dormitory Room Assignment (represented by a ‘building’ icon on the menu 


bar). 


Each selection opens a separate window which is a gateway to these distinct 
areas of operation. The Administrative part of the application serves for creating new 
student record, and for viewing and editing student biographical and administrative data. 
The Physical Training & Weight Control part of the application allows to create, edit, and 
query data related to physical training and weight control. The Dormitory Room 
Assignment portion of the application provides an interface for assigning students to 
dormitory rooms. Whenever a selection of a person from a list of personnel is needed 
before any data can be retrieved, the Locator appears automatically on the screen. By 
clicking a name of a person, retrieval and display of data is triggered. Anytime the type 
of a report needs to be determined before data can be retrieved, a popup menu prompts 


the user for selection from a list of reports and forms. 
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User can see only names and records that he/she is authorized to access. 
Records can be edited by clicking on selected data item and typing new value. 
Navigation between fields can be achieved by pressing the TAB or ENTER key. Saving 
the data can be triggered by clicking the ‘Save’ icon in menu bar, or by selecting ‘Save’ 
from the main menu. The ‘Save’ feature is automatically enabled/disabled, depending on 
user's privileges. Displayed data can be sent to a printer, or exported to a text file. Both 
features are available in the File menu on the main menu. 

Global users, who have access to data from more than one Unit, see slightly 
modified main menu with added Capabilities. Their menu contains an icon for every Unit 
in the database. Global user can freely switch from one Unit to another. After each 
switch, names in the Locator are automatically replaced by names from selected Unit. 

The MILDB application, in its final version, is a multifaceted application with a 
wealth of features. It has been noted, however, that by organizing the application's 
interface into logical groups, and by providing visual guidance and clues to users during 
each action, it is easy to use. Generally, only about 20 minute briefing is need for a new 


user to become proficient in using all major features of MILDB. 
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VI. CONCLUSION 


Implementation of a two-tier client/server model, proposed in this thesis, provides 
only an interim solution. Growing demands for data exchange will soon command 
implementation of a new, fault-tolerant system that will provide faster response and 
easier, yet secure, access to information. Next research should, therefore, focus on the 
development of a client/server model that will be built on an open systems foundation 
and will meet these demands, allowing to integrate new client/server software systems 
and various middleware and application standards as they emerge. The resulting 
client/server model should ensure continuous systems' interoperability, scalability, and 


portability in the heterogeneous computing environment at the Presidio of Monterey. 
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APPENDIX A 


Documentation of MILDB Database schema includes: 


e@ ADMINBASE table with reference tables 
e Tables depending on ADMINBASE 
@ Reference tables 


e Views 
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Table ADMINBASE with Reference Tables: 
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Tables depending on ADMINBASE: 





pay_code 
pay_gid 
Seat: plt 
pmos 
q_diab 
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Be 
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al 

:  alt_event 

: alt ser 

apft_type 

ja J apft 

pu_reps 

|  pu_scr 

i tun_ser 

;  tun_tm 

<= ssn 
a15 jag_ap 
al5_ type 
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< id 
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pit_expr3 

















Tables depending on ADMINBASE (continued): 
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MILDB Reference Tables: 
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MILDB Reference Tables (continued): 
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MILDB Views: 


d_artival 
d_depart 
d_dlab 
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awol_tmks 
awol_spers 
d_awol 
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APPENDIX B 


Documentation of MILDB table and view definition includes: 


e Definition of table ADMINBASE 
e Definition of tables referenced by ADMINBASE 
e Definition of views 


e Definition of stored procedures 
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CREATE TABLE [mil].[CLASS] ( 
[I SITE] [varchar] (3) NOLL , 
[C_LVL] [varchar] (2) NULL , 
[C_LANG] [varchar] (2) NULL , 
[I WKS] [varchar] (2) NULL , 
[C_ LOC) [varchar] (1) NULL , 
[I_ ITER] [varchar] (3) NULL , 
[t.FY] {varehex | (2) NULL , 
[C_CLASS] [varchar] (12) NOT NULL , 
[D_ OPEN] [datetime] NULL , 
[D CLOSE] [datetime] NULL , 
[D GRAD] [datetime] NULL , 
[D RPT] [datetime] NULL , 
[Q ORIG SCH] [float] NULL , 
[Q CURR_SCH] [float] NULL , 
[C_DIR] [varchar] (3) NULL , 
[C_FLAG] [varchar] (1) NULL , 
[D LOG] [datetime] NOLL , 
[N USER] [varchar] (8) NULL , 
[F_CQMS] [varchar] (1) NULL , 
[staarchive] [varchar] (1) NULL 
) 
GO 


CREATE TABLE [mil].[unit auth] ( 
[n_user] {fvarchar] (8) NOT NULL , 
(unit] [varchar] (1) NOT NULL , 
[plt] [varchar] (1) NOT NULL 

)} ON [PRIMARY] 

GO 


CREATE TABLE [mil].[ARMYCOMP] ( 
[COMP] [varchar] (3) NOT NOLL , 
[XX] [varchar] (2) NULL , 

[E COMP] [varchar] (45) NULL , 
[D TRAN] [datetime] NULL , 

[N USER] [varchar] (8) NULL , 
[lineid] [numeric] (18, 0) NULL. 


CREATE TABLE [mil]. [ARMYUNIT] ( 
[UNIT] [varchar] (1) NOT NULL , 
[XX] [varchar] (2) NULL , 

[N UNIT] [varchar] (30) NULL , 
[D TRAN] [datetime] NULL , 

[N USER] fvarchar} (8) NULL , 
flineid] [numeric] (18, 0) NULL 
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CREATE TABLE [mil].[M STAT] ( 
[MAR STAT] [varchar] (1) NOT NULL , 
[XX] [varchar] (2) NULL , 
[MS DESC] [varchar] (22) NULL , 
([D TRAN] [datetime] NULL , 
(N_USER] [varchar] (8) NULL 


CREATE TABLE [mil].[QUOTA] ( 
{[OS1] [varchar] (2) NOT NULL , 
[OS2] [varchar] (2) NULL , 
[XX] [varchar} (2) NULL , 
[QUOTA] [varchar] (45) NULL , 
[D TRAN] [datetime] NULL , 

(N USER] [varchar] (8) NULL 


CREATE TABLE [mil].[RACE] ( 
[RACE CODE] [varchar] (1) NOT NULL , 
[XX] [varchar] (2}) NULL , 
[RACE] [varchar] (10) NULL , 
[D TRAN] [datetime] NULL , 
[N USER] [varchar] (8) NULL 


CREATE TABLE [mil].[SERVICE] ( 
[SERVICE] [varchar] (1) NOT NULL , 
[N SERV] [varchar] (20) NULL , 
[SERV_ABBR] [varchar] (4) NULL , 
[D TRAN] [datetime] NULL , 
[N USER] [varchar] (8) NULL 


CREATE TABLE [mil]. [SM STAT] ( 
[SM_STATUS] [varchar] (1) NOT NULL , 
[XX] [varchar] (2) NULL , 

[SM STAT DE] [varchar] (21) NULL , 
[D_ TRAN] [datetime] NULL , 
[N_ USER] [varchar] (8) NULL 


CREATE TABLE [mil].[ADMINBASE] ( 
{BASD] [datetime] NULL , 
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[BPED] [datetime] NULL , 

[BRANCH] [varchar] (2) NULL , 
[CLASS] [varchar] (12) NULL , 
[COMP] [varchar] (3) NULL , 

[DOB] [datetime] NULL , 

[D ARRIVAL] [datetime] NULL , 

[D DEPART] [datetime] NULL , 
[D_DLAB] [datetime} NULL , 
[D_RANK] fdatetime] NULL , 

[D UNIT] [datetime] NULL , 

[ETS] [datetime] NULL , 

[LiC_ 1]. [varchar } (2) NULL , 

[LIC 2] [varchar] (2) NULL , 

[MAR STAT] [varchar] (1) NULL , 
[MEALCARD] [varchar] (9) NULL , 
[N_ STUDENT] fvarchar] (27) NULL , 
[PAY CODE] [varchar] (2) NULL , 
[PAY GRD] [varchar] (2): NULL: ~ 
[PLT] [varchar] (2) NOT NULL , 
[PMOS] [varchar] (9) NULL , 

[Q DLAB] [smallint] NULL , 

[OS1] [varchar] (2) NULL , 

[RACE] [varchar] (1) NOLL , 
[RANK] [varchar] (6) NULL , 
([RMKS1] [varchar] (20) NULL , 
[SERVICE] [varchar] (1) NULL , 
fSEX] [varchar] (1) NULL , 

[SM STATUS] [varchar] (1) NULL , 
[SOD] [varchar] (2) NULL , 

[SSN] [varchar] (9) NOT NULL , 
[ULT MOS} [varchar] (9) NULL , 
[UNIT] [varchar] (1) NULL , 

[Q AGE] (real} NULL , 

[D TRAN] {[datetime] NULL , 

[N_ USER] [varchar] (8) NULL , 
[PlaceOfBirth] [varchar] (30) NULL , 
{d ArrvOnPost] [datetime] NULL , 
[t_ArrvOnPost ] [datetime] NULL , 
[d EstArrv] [datetime] NULL , 
[UnitDepart] [varchar] (40) NULL , 
[InterimBillet] [varchar] (255) NULL , 
[LangToStudy] [varchar] (40) NULL , 


[Inprocessed] [varchar] (1) NULL , 
[n_user_ arrv] [varchar] (16) NULL , 
[d_ tran _arrv] [datetime] NULL , 
[rec stat] [varchar] (1) NULL 


ALTER TABLE [mil].[CLASS] WITH NOCHECK ADD 
CONSTRAINT [PK_CLASS] PRIMARY KEY CLUSTERED 


( 
[C CLASS] 
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) ON [PRIMARY] 
GO 


ALTER TABLE [mil]. [ARMYCOMP] WITH NOCHECK ADD 
CONSTRAINT [PK ARMYCOMP] PRIMARY KEY CLUSTERED 
( 
[COMP] 
) ON [PRIMARY] 
GO 


ALTER TABLE [mil]. [ARMYUNIT] WITH NOCHECK ADD 
CONSTRAINT [PK _ARMYUNIT] PRIMARY KEY CLUSTERED 
( 
{UNIT ] 
) ON [PRIMARY] 
GO 


ALTER TABLE [mil].[{M STAT] WITH NOCHECK ADD 
CONSTRAINT [PK M STAT] PRIMARY KEY CLUSTERED 
( 
[MAR STAT] 
) ON [PRIMARY] 
GO 


ALTER TABLE [mil]. [QUOTA] WITH NOCHECK ADD 
CONSTRAINT [PK QUOTA] PRIMARY KEY CLUSTERED 


( 
[QS1] 
) ON [PRIMARY] 
GO 


ALTER TABLE [mil]. [RACE] WITH NOCHECK ADD 
CONSTRAINT [PK RACE] PRIMARY KEY CLUSTERED 
( 
[RACE CODE] 
) ON [PRIMARY] 


GO 


ALTER TABLE [mil]. [SERVICE] WITH NOCHECK ADD 
CONSTRAINT [PK SERVICE] PRIMARY KEY CLUSTERED 
— 
[SERVICE] 
) ON [PRIMARY] 
GO 


ALTER TABLE [mil]. [SM_STAT] WITH NOCHECK ADD 
CONSTRAINT [PK _SM STAT] PRIMARY KEY CLUSTERED 


169 


{ 
[SM_ STATUS] 


. ON [PRIMARY] 
GO 


ALTER TABLE [mil] .[ADMINBASE] WITH NOCHECK ADD 
CONSTRAINT [PK _ADMINBASE] PRIMARY KEY CLUSTERED 
( 
[SSN] 
) ON [PRIMARY] 
GO 


ALTER TABLE [mil] .[ADMINBASE] WITH NOCHECK ADD 


CONSTRAINT [DF _ADMINBASE PLT] DEFAULT ("' ') FOR [PLT], 

CONSTRAINT [DF ADMINBASE D TRAN 1 14] DEFAULT (getdate()) FOR 
[D TRAN], 

CONSTRAINT [DF_ADMINBASE_N_USER_2 14] DEFAULT (user_name(null)) FOR 
[(N USER], 

CONSTRAINT [DF _ADMINBASE rec _stat_3 14] DEFAULT ('A') FOR 
[rec_stat] 


GO 


CREATE INDEX [i unitplt] ON [mil}].f{unit auth] ([unit], [pit]) ON 
[PRIMARY ] 
GO 


CREATE INDEX [i_unitplt] ON [mil]. [ADMINBASE} ([UNIT], [PLT]) ON 


[PRIMARY ] 
GO 


ALTER TABLE [mil] .[ADMINBASE] ADD 
CONSTRAINT [FK_ADMINBAS REF_1672 CLASS] FOREIGN KEY 


( 
[CLASS] 
) REFERENCES [mil].[CLASS] ( 
[C_CLASS] 
), 
CONSTRAINT [FK ADMINBAS REF 1675 ARMYUNIT] FOREIGN KEY 
( 
[UNIT] 
) REFERENCES [mil].[ARMYUNIT] ( 
[UNIT] 
)y 
CONSTRAINT [FK_ADMINBAS REF_1678 ARMYCOMP] FOREIGN KEY 


f 


( 
[COMP ] 

) REFERENCES [mil].[ARMYCOMP] ( 
[COMP] 


~~ 
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CONSTRAINT [FK_ADMINBAS REF 1691 QUOTA] FOREIGN KEY 
( 


[Os.] 
) REFERENCES [mil].[QUOTA] ( 
[QS1] 
), 
CONSTRAINT [FK ADMINBAS REF 1694 SERVICE] FOREIGN KEY 
( 
[ SERVICE] 
) REFERENCES [mil].[SERVICE] ( 
[SERVICE] 
), 
CONSTRAINT [FK_ADMINBAS REF 1697 RACE] FOREIGN KEY 
( 
[RACE] 
) REFERENCES [mil].[RACE] ( 
[RACE_CODE] 
ds 
CONSTRAINT [FK ADMINBAS REF_1700_ M STAT] FOREIGN KEY 


/ 


\ 
[MAR STAT] 

) REFERENCES [mil].{M STAT] ( 
[MAR STAT] 

y 

CONSTRAINT [FK ADMINBAS REF 5470 SM STAT] FOREIGN KEY 

( 
[SM STATUS] 

) REFERENCES [mil].[SM STAT] (¢ 
[SM STATUS] 

) 

GO 


CREATE VIEW mil.ADMIN AS 


SELECT BASD, BPED, BRANCH, CLASS, COMP, DOB, D ARRIVAL, 
D DEPART, D DLAB, D_ RANK, D_ UNIT, ETS, LIC 1, LIC 2, 
MAR STAT, MEALCARD, N STUDENT, . PAY CODE, PAY GRD, 
PLT, PMOS, Q DLAB, QS1, RACE, RANK, RMKS1, SERVICE, 
SEX, SM_STATUS, SOD, SSN, ULT_MOS, UNIT, Q AGE, 

D TRAN, N USER; rec stat, PlaceOfBirth 
FROM mil.ADMINBASE 
WHERE EXISTS 
(SELECT * 
FROM mil.unit_auth u 
WHERE mil.ADMINBASE.unit + mil.ADMINBASE.plt LIKE u.unit 
+ Uplt- AND: usm USER..= USER) 


CREATE VIEW mil.admin miix AS 
SELECT mil.ADMINBASE.basd, 
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Maid 
Mieloy 
sate a 
mil. 
mil. 
94 Boe 
mil. 
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TR 
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mii. 
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ML. 
Ma 
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mi 
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Ma < 
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Ts bss 


ADMINBASE. 
ADMINBASE. 
ADMINBASE. 
ADMINBASE. 
ADMINBASE. 
ADMINBASE. 
ADMINBASE. 
. ADMINBASE. 
. ADMINBASE. 
. ADMINBASE. 
- ADMINBASE. 
.ADMINBASE. 
ADMINBASE. 
. ADMINBASE 


ADMINBASE 


adminbase. 
ADMINBASE. 


FROM mil.ADMINBASE 


bped, 
branch, 
class, 
Comp, 
dob, 

d_ arrival, 
d_ depart, 
d_dlab, 
d_rank, 
GQ.unit, 
ets, 

ni one 
Lue. 24 


-mar_ stat, 
-mealcard, 
. ADMINBASE. 
ADMINBASE. 
. ADMINBASE. 
.ADMINBASE. 
.ADMINBASE. 
. ADMINBASE. 
ADMINBASE. 
. ADMINBASE. 
.ADMINBASE. 
ADMINBASE. 
. ADMINBASE. 
. ADMINBASE. 
. ADMINBASE. 
. ADMINBASE. 
. ADMINBASE. 
. ADMINBASE. 
. ADMINBASE 
. ADMINBASE. 
ADMINBASE. 
. ADMINBASE. 


n student, 
pay code, 
pay_grd, 
Dicy 

pmos, 

q diab, 
gsi, 

race, 
rank, 
rmksl, 
service, 
sex, 

sm_ status, 
sqd, 

ssn, 

ult mos, 


Pp boas oe 


G_age, 
_tran, 
n USER, 


placeofbirth, 


Tec. ocak 





WHERE EXISTS (SELECT * FROM mil.unit_auth u 
WHERE mil.ADMINBASE.unit+mil.ADMINBASE.plt. 


LIKE u.unitt+u.plt AND u.n_USER = USER) 


CREATE VIEW mil.apft AS 
SELECT. °* 
FROM MIL.apftbase 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE MIL.APFTBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.ART15 AS 


172 











SELEcL-* 
FROM MIL.ARTISBASE ARTISBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE ARTISBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.AWOL AS 
SELECT * 
FROM MIL.AWOLBASE AWOLBASE 
WHERE EXISTS ( SELECT * 
FROM MIL.ADMIN W 
HERE AWOLBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.BAR AS 
SELECT * 
FROM MIL.BARBASE BARBASE 
WHERE EXISTS -SELECT * 
FROM MIL.ADMIN 
WHERE BARBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.BRKS ACT AS 
SELECT * 
FROM mil.BRKS ACTBASE 
WHERE EXISTS (SELECT * 
FROM mil-unit auth u 


WHERE mil.BRKS ACTBASE.company = u.unit AND u.n_USER 


= USER) 


CREATE VIEW mil.CC_TRNG AS . 
SELECT * 
FROM MIL.CC_TRNGBASE CC TRNGBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE CC_TRNGBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.CHAP AS 
SELECT. * 
FROM MIL.CHAPBASE CHAPBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE CHAPBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.DEPN AS 
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SELECT’ 
FROM MIL.DEPNBASE DEPNBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE DEPNBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.FCARE AS 
SELECT * 
FROM MIL.FCAREBASE FCAREBASE 
WHERE: EXISTS SELECT = 
FROM MIL.ADMIN 
WHERE FCAREBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.FLAG AS 
SELECT * 
FROM MIL.FLAGBASE FLAGBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE FLAGBASE.SSN=MIL.ADMIN. SSN) 


CREATE VIEW mil.FORM90 AS 
SELECT * 
FROM MIL.FORM9OBASE FORMSOBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE FORMSOBASE.SSN=MIL. ADMIN. SSN) 


CREATE VIEW mil.ISSR AS 
SebEC = 
FROM MIL.ISSRBASE ISSRBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE ISSRBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.LOC AS 
SELECT * 
FROM MIL.LOCBASE LOCBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE LOCBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.LPTH AS 
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SELECT = 
FROM MIL.LPTHBASE LPTHBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE LPTHBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.irt plan AS 
SELECT * 
FROM MIL.1lrt planBASE Ilrt planBASE 
WHERE lrt planBASE.C_UNIT IN (SELECT MIL.UNIT AUTH.UNIT 
FROM MIL.UNIT AUTH 
WHERE MIL.UNIT AUTH.N USER=USER) 


CREATE VIEW mil.M TRNG AS 
SELECT * 
FROM MIL.M TRNGBASE M_TRNGBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE M TRNGBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.OFFICE AS 
SELECT .* 
FROM MIL.OFFICEBASE OFFICEBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE OFFICEBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.PREG AS 
SELECT = 
FROM MIL.PREGBASE PREGBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE PREGBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.PRM PRTY AS 


SELECT * 
FROM MIL.PRM PRTYBASE PRM PRTYBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 


WHERE PRM PRTYBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.PROF AS 
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SELECT: .* 
FROM MIL.PROFBASE PROFBASE 
WHERE EXISTS ( SELECT * 
FROM MIL.ADMIN 
WHERE PROF BASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.TRNG AS 
SELECT * 
FROM MIL.TRNGBASE TRNGBASE 
WHERE EXISTS( SELECT * | 
FROM MIL.ADMIN 
WHERE TRNGBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.URINE AS 
SELECT. * 
FROM MIL.URINEBASE URINEBASE 
WHERE EXISTS{ SELECT * 
FROM MIL.ADMIN 
WHERE URINEBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.v_cansee AS 
SELECT * FROM Mil. unse.auch 
WHERE n USER=USER 


CREATE VIEW mil.WC AS 
SELECT -* 
FROM MIL.WCBASE WCBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE WCBASE.SSN=MIL.ADMIN.SSN) 


CREATE VIEW mil.wpn AS 
DEbaCr = 
FROM MIL.wpnBASE wpnBASE 
WHERE EXISTS( SELECT * 
FROM MIL.ADMIN 
WHERE wpnBASE.SSN=MIL.ADMIN.SSN) 
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CREATE PROCEDURE mil.changessn ( @oldssn varchar(9), 
varchar (9))AS 


SELECT * INTO #tempbaseadmin 
FROM mil.adminbase 
WHERE mil.adminbase.ssn 


UPDATE #tempbaseadmin 


SET ssn = @newssn, n_USER 
WHERE ssn = @oldssn 


INSERT INTO mil.adminbase 
SELECT * FROM #tempbaseadmin 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 
UPDATE mil 
= @oldssn 
UPDATE mil 
= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


GRAM 


HHQ 


.CC_TRNGBASE 


.-APETBASE 


ISSRMASTBASE 
LOI 
ART1SBASE 
AWOLBASE 
BARBASE 
BRKS_ ACT 
CHAPBASE 
OFFICEBASE 
DEPNBASE 
PROFILES 
FCAREBASE 
FLAGBASE 
FORM90BASE 
ISSRBASE 
LOCBASE 


LPTHBASE 


@oldssn 
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USER, d_tran 


SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 


SET 





@newssn 
= GETDATE () 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 
ssn @newssn 





WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 


WHERE 


ssn 


ssn 


Ssn 


ssn 


ssn 


ssn 


ssn 


ssn 


ssn 


ssn 


ssn 


ssn 


ssn 


ssn 


ssn 


ssn 


ssn 


ssn 


ssn 


ssn 





UPDATE mil.M TRNGBASE SET ssn = @newssn WHERE ssn 


= @oldssn 

UPDATE mil. PREGBASE SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil.SEC SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil.PRM PRTYBASE SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil. PROFBASE SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil.BARI SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil.REPRBASE SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil.RESRV SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil.TRNG SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil.CO_ FEED | SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil.wpnBASE SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil. TARGET SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil.CST SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil.TRNGMSTR SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil.URINEBASE SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil.VEH SET ssn = @newssn WHERE ssn 
= @oldssn 

UPDATE mil.WCBASE SET ssn = @newssn WHERE ssn 
= @oldssn : 


DELETE FROM mil.adminbase 
WHERE mil.adminbase.ssn = @oldssn 


GO 


CREATE PROCEDURE mil.changeviewssn ( @oldssn varchar(9), @newssn 
varchar (9))AS 


SELECT * INTO #tempviewadmin 
FROM mil.admin 
WHERE mil.admin.ssn = @oldssn 


UPDATE #tempviewadmin 
SET ssn = @newssn, n_USER = USER, d_tran = GETDATE() 


WHERE ssn = @oldssn 


INSERT INTO mil.adminbase 
SELECT * FROM #tempviewadmin 
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UPDATE: mil 
= @oldssn 
UPDATE mil 
= @oldssn 
UPDATE mil 
= @oldssn 
UPDATE mil 
= @oldssn 


UPDATE mil. 


= @oldssn 
UPDATE mil 
= @oldssn 
UPDATE mil 
= @Goldssn 
UPDATE mil 
= @oldssn 


UPDATE mil. 


= @oldssn 
UPDATE mil 
= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mail. 


= @oldssn 


UPDATE: mid . 


= @oldssn 
UPDATE mil 
= @oldssn 
UPDATE mil 
= @oldssn 
UPDATE mil 
= @oldssn 


UPDATE mil. 


= @oldssn 
UPDATE mil 
= @oldssn 


UPDATE mil. 


= @oldssn 


UPDATE mil. 


= @oldssn 
UPDATE mil 
= @oldssn 


. GRAM 
. HHO 
.CC_TRNG 


-APFT 


ISSR 


LOL 


.ARTI15 


. AWOL 


BAR 


.BRKS_ACT 


CHAP 


GrrICE 


DEPN 


PROF LLES 


FCARE 


FLAG 


FORM90 


ISSR 


. LOC 
.LPTH 


.M_TRNG 


PREG 


wEC 


PRM PRTY 


PROF 


. BARL 


SET 


Sb T 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
Sek 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 
SET 


SET 
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ssn 


ssn 


Soll 


ssn 


ssn 


ssn 


S30 


ssn 


ssn 


ssn 


ssn 


ssn 


ssn 


Sol 


ssn 


2oll 


ssn 


ssn 


ssn 


ssn 


ssn 


SsSsn 


ssn 


ssn 


ssn 


ssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 


@newssn 
@newssn 
@newssn 
@newssn 


@newssn 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


WHERE 


ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 
ssn 


Ssn 


UPDATE mil.REPR SET ssn = @newssn 
= @oldssn 

UPDATE mil.RESRV SET ssn = @newssn 
= @oldssn 

UPDATE mil.TRNG SET ssn = @newssn 
= @oldssn 

UPDATE mil.CO_ FEED SET ssn = @newssn 
= €@oldssn 

UPDATE mil.wpn SET ssn = @newssn 
= @oldssn 

UPDATE mil. TARGET SET ssn = @newssn 
= @oldssn 

UPDATE mil.CST SET ssn = @newssn 
= @oldssn 

UPDATE mil.TRNGMSTR SET ssn = @newssn 
= @oldssn 

UPDATE mil.URINE SET ssn = @newssn 
= @oldssn . | 

UPDATE mil.VEH SET ssn = @newssn 
= @oldssn 

UPDATE mil.WC SET ssn = @newssn 
= @oldssn 


DELETE FROM mil.admin 
WHERE mil.admin.ssn = @oldssn 


GO 


CREATE PROCEDURE mil.getRecordStatus ( @newssn varchar(9) )AS 
declare @recstat varchar (1) 


SELECT @recstat = rec_stat 
FROM mil.adminbase 
WHERE ssn = @newssn 


return convert( int, @recstat) 


GO 


CREATE PROCEDURE mil.getSUID( @TABLE NAME VARCHAR (384) , 
@TABLE USER VARCHAR (384), @TABLE PERMS VARCHAR (4) OUTPUT) 


AS 


if ( @TABLE NAME is null) OR ( @TABLE USER is null) 


begin 
raiserror 20001 'Must provide table name AND USER ID.' 


return 
end 
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WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 
WHERE 


WHERE 





ssn 
SST 
ssn 
ssn 
ssn 
Ssii 
ssn 
ssn 
ssn 
ssn 


ssM 














DECLARE @sel char(1) 
DECLARE @updt char(1) 
DECLARE @insrt char(l) 
DECLARE @dlt char(1) 


SELECT @sel = '?! 

SELECT @updt = '?! 

SELECT @insrt = '?' 

SELECT @dlt = '?! 

SELECT @sel = 'S' FROM sysprotects p, sysobjects o, sysUSERs u, 


sysmembers m 

WHERE p.id = o.1id 

and o.type IN ('U','V','S') AND object name(o.id) = @TABLE NAME 

and USER name(u.uid) = @TABLE USER 

and (u.uid > 0 AND u.uid < 16384) 

and ((p.uid = u.uid) OR (p.uid = m.groupuid AND u.uid = m.memberuid) ) 
AND p.action = 193 /*SELECT*/ 


SELECT @updt = 'U' FROM sysprotects p, sysobjects o, sysUSERs u, 
sysmembers m 

WHERE p.id = o.id 

and o.type IN (‘'U!,'V','S') AND object _name(o.id) = @TABLE NAME 

and USER name(u.uid) = @TABLE USER 

and (u.uid > 0 AND u.uid < 16384) 

and ((p.uid = u.uid) OR (p.uid = m.groupuid AND u.uid = m.memberuid) ) 
AND p.action = 197 /*UPDATE*/ 


SELECT @insrt = 'I' FROM sysprotects p, sysobjects o, sysUSERs u, 
sysmembers m | 

WHERE p.id = o.id 

and o.type IN ('U','V"','S') AND object _name(o.id) = @TABLE NAME 

and USER name(u.uid) = @TABLE USER 

and (u.uid > 0 AND u.uid < 16384) 

and ((p.uid = u.uid) OR (p.uid = m.groupuid AND u.uid = m.memberuid) ) 
AND p.action = 195 /*insert*/ 


SELECT @dlit = 'D' FROM sysprotects p, sysobjects o, sysUSERs u, 
sysmembers m 

WHERE p.id = 0.id 

and o.type IN ('U','V",'S') AND object_name(o.id) = @TABLE NAME 

and USER name(u.uid) = @TABLE USER 

-and (u.uid > O AND u.uid < 16384) 

and ((p.uid = u.uid) OR (p.uid = m.groupuid AND u.uid = m.memberuid) ) 
AND p.action = 196 /*delete*/ 


SELECT @TABLE PERMS = @sel + @updt + @insrt + @dit 


GO 
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CREATE PROCEDURE mil.isInAdminbase( @newssn varchar(9), @recstat 
varchar(1) OUTPUT) AS 


SELECT: @recstat= *7" 
SELECT: @recstat. = rec stat 
FROM mil.adminbase 


WHERE ssn = @newssn 


GO 
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